Saving REST API IDs into a different microservice

Question

I'm not sure how to best ask this, as it's the first time I have to tackle such stuff. It might be that it's a common problem and I'm just using the wrong keywords to search. Basically, imagine a microservice needs (as part of its data) the ID of some objects managed by another microservice. For example, Users and Orders: the Orders microservice needs the ID of the user who placed the order, as exposed by the Users microservice.

This leads to two questions:

• Is it good practice to save the user id for a user in the orders microservice (that is, in the database that backs the microservice)? (or, in the general case, the ID of an object managed by a microservice in another one)
• How does a consumer of either API finds out the user ID for a user (or the order ID) to use to start making actual REST API calls? Normally only some generic identifier comes from the application, like an email address or telephone number. I guess there must be some kind of mapping service which, given an email or a phone number, returns the user ID to use for the REST calls? Where should this translation service be exposed? In the Users microservice?

Thanks

Answer 1

Is it good practice to save the user id for a user in the orders microservice (that is, in the database that backs the microservice)? (or, in the general case, the ID of an object managed by a microservice in another one)

If it wasn't, then you'd be patently unable to ever link two resources that come from different microservices.

It's good that you're already focusing on the ID of the user, not the entire user's data, because that is precisely what the default approach for microservices is. You only store the reference to the resource in other microservices. The actual data stays in the "home" microservice, and other microservices have to request it (based on the stored reference).

That being said, there are cases where you do want to copy over some data, but this is highly contextual and comes with its own cost. As a baseline, you should try to avoid these situations and only store references (i.e. IDs) external to the "home" microservice.

I guess there must be some kind of mapping service which, given an email or a phone number, returns the user ID to use for the REST calls? Where should this translation service be exposed? In the Users microservice?

Since the Users microservice is the only service that stores the user's data, it is inherently the only one able to translate a data field to an ID. So yes, the Users microservice should expose an API endpoint to provide this functionality.

Whether this is a targeted endpoint (get user ID by email) or a broad one (get users, with many possible filters); depends on what makes the most sense in your scenario.

Answer 2

I guess there must be some kind of mapping service which, given an email or a phone number, returns the user ID to use for the REST calls? Where should this translation service be exposed? In the Users microservice?

In general, that is not a good idea. Microservices exist for a reason. That reason is usually independent scalability, independent operation, independent development, etc. Depending on a different service for data query is therefore a dangerous road to go down on. It destroys most of the reasons microservices usually exist for.

What's the alternative? Well, depends on the exact case. Normally user ids are contained in the token the user already has. So any service seeing a token (JWT for example) should already have the user id. There's no need to ask somebody else.

Things like order id can have multiple solutions. Easiest one is of course fulfilling the order from one service. No need to get other services involved, or other services may have their own id if additional steps are needed in the process.

If that doesn't work, the order process must carry the order id (if it's that important) all the way through where each callee (service) can see it.

In general, having "Users", "Orders" services do not sound right though. Services should handle use-cases in their entirety, not be glorified database tables. You get all sorts of problems if you do that.