What are the approches to to fetch common data btween microservices without replication?

Question

One of the alternatives for managing common data between microservices is replicating the data needed by multiple services in their own databases but there are large data sets that we do not want to replicate.

I'm using as an example the Food Ordering Application used in the book Microservices Patterns by Chris Richardson where they have these main services:

• Consumer service
• Ordering service
• Kitchen service
• Accounting service

If we wanted a client app to display all of the pending orders we would call the ordering service to get all of the pending orders but the ordering service only stores the orders consumer id and the client needs to display the consumer's full name.

I see two approaches:

• to have the client call a the consumer service for each order received by the order service and look for the consumer full name
• to have the order service expand the data, that is, when the pending orders are requested the order service will call the consumer service to get the consumer's full name and return the data already expanded

Is there a best practice to deal with this? Are any of these approaches frowned upon? Are there other common alternatives that I'm missing?

Answer 1

There isn't much difference between the client fetching the consumer name and the ordering service fetching the consumer name. Both will result in two request/response cycles with the same data output.

I prefer to make the client perform the requests mostly just because it's more tractable. If every time you send a service a request, that service sends off its own requests to other services (which might likewise send off their own requests) it becomes an absolute nightmare to debug. If the client makes all the calls then you can identify which service is malfunctioning very quickly.

If the client is a browser you are also offloading some of the work away from your servers.

I don't know how similar your actual code base is to the example. The example is, however, a very bad example of when it makes sense to use a microservice. You're essentially treating your microservices as tables in a database. And every time you want to perform a table join you're making multiple requests. That's ridiculous. And what about integrity constraints? If these services have their own dbs then how will the ordering service know when a customer has been deleted from the customer service's database?

Microservices work best for encapsulating stateless functions. Not database tables. Have one database that everyone can access. Put one API on top of it if you need with different views for returning client data/ order data etc.