Basic microservice design problem re shared data

Question

Scenario

I'll use a hypothetical for the purposes of getting to the design problem I think is relevant.

I have an 'orders' microservice which, rather obviously, owns orders made by my users.

I also have an inventory microservice which tracks products.

The orders microservice, is capable of serving up a list of orders to a web UI. Fine so far (if my hypothetical is wrong in any way up to now feel free to correct).

The Problem

The orders microservice has product IDs against each order ready for any look-up to the inventory microservice, but orders doesn't have the product name.

Solutions

Essentially, at the point of rendering the list of orders, we need the product name (to display to the user, they're not interested in guids).

• There are 2 requests, first request is to the orders microservice, second is to the inventory service
• Orders domain also stores product names

None of these solutions seem 'nice' to me. There's either data duplicated across multiple domains or we're incurring the overheads of implementing our own relation across domains without the benefits of an RDMS if they were to live in the same monolith. If orders were to store some product details, it'd have to stay in sync, which implies messaging between the services.

Question

Which solution (either one of the 2 above or a different one) is more conducive to a 'good' microservices design?

Answer 1

None of these solutions seem 'nice' to me. There's either data duplicated across multiple domains or we're incurring the overheads of implementing our own relation across domains without the benefits of an RDMS if they were to live in the same monolith

I would argue that both are valid strategies in microservices world and are the expected consequence of this architecture approach.

Which solution (either one of the 2 above or a different one) is more conducive to a 'good' microservices design?

Data duplication is something you should not be afraid in microservice architecure, it is actually quite common approach - the owner service manages the corresponding data and send/streams events (possibly domain ones) and all interested clients subscribe to them and if needed maintain local "readonly" (i.e. the only source of change - events from owner) copy (for example in "local" service database). So personally I would look into the data duplication approach.