There’s a common and quite interesting question about how to manage Ids in a microservices architecture. This question is best described with an example, so let’s say we have two bounded contexts,
Support, that work in their own respective microservices:
Notice that there is the same entity,
Customer, in both of these microservices. Let’s also say that the
Sales microservice is upstream to
Support microservice. When a customer is created in
Sales, it is propagated via a service bus to
Support that creates its own representation of that customer.
And so the question here is:
Supportmicroservice use the same Id as as
Salesor should it assign its own Id to its version of the customer?
If you use UUIDs (GUIDs), then you can easily assign separate Ids to
Customer in both microservices, such that the Ids in the two bounded contexts won’t overlap.
But is it a good thing to do?
No, it isn’t. The
Support microservice should use the same Id as the
Sales microservice. Use the same Id across your system, as long as this Id is generated by one of your microservices.
The Id is just another property, it represents the identity of the customer. This identity is controlled by the microservice that creates
In our example, that would be
Sales. New customers are created when your company sells something to them. And so,
Sales is the master-microservice for the identity of all customers. Only the
Sales microservice can assign that identity. The downstream microservices should replicate it to their own databases, similar to how they replicate
When you look at Ids from this perspective, it becomes clear that it doesn’t make sense to assign separate customer Ids in downstream microservices, just like it doesn’t make sense to assign different names or email addresses.
As long as only one microservice controls the lifetime of a particular entity (i.e. can create and delete it), you will always have just one Id within your system, even if that system consists of multiple microservices.
But what if the Id comes from an external system?
Let’s say that customers can register in your system via their social profiles, such as Facebook. In this scenario, Facebook will provide its own Id to your system.
Should you use that Facebook Id as-is?
No, you need to create your own customer Id and save the Facebook Id as a separate (optional) field.
The difference here is that you don’t have control over the Ids Facebook provides you. Facebook can potentially change those Ids and mess up your system entirely.
The contract between your microservices is much stronger than that between your system and Facebook. You can (and should) maintain backward compatibility among the microservices in your system. There’s no guarantee of such compatibility between your system and Facebook.
Enjoy this message? Here are more things you might like:
Workshops — I offer a 2-day workshop for organizations on Domain-Driven Design and Unit Testing. Reply to this email to discuss.
Unit Testing Principles, Patterns and Practices — A book for people who already have some experience with unit testing and want to bring their skills to the next level.
Learn more »
My Pluralsight courses — The topics include Unit Testing, Domain-Driven Design, and more.
Learn more »