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, Sales and 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:

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 Customer instances.

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 Name or Email properties.

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.

--Vlad

https://enterprisecraftsmanship.com