1

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?

1
  • In this scenario the ordering service should have a copy of the relevant data about the consumer that placed the order. If that data is very large, and all of it is needed, then consumer/ordering should probably not be separate services.
    – doubleYou
    Sep 19 at 17:07
0

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.

2
  • 1
    Thank you for assuring me I am not alone in this thinking. Microservices-at-any-cost is a plague on efficiency, integrity and simplicity not to mention development time. Sep 17 at 3:01
  • My code is similar in that we would have two services interacting with our equivalent of the consumer. In our case the consumer is managed by an external system so the only options I see are either replicating the data or consuming the services provided by the external application. Regarding the example it is the exampled followed through one of the definitive books on microservices. It might be that since I have some chapters left this is later explained and refactored.
    – Dishware
    Sep 17 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.