Microservices Architecture: Chatty services or data duplication

Question

TL;DR Should a service opt for saving data in its local database that it needs occasionally, or request the data every time from the service that the data originated from?

Let's have some generic example of a web store / ordering app. Service A is a user session management service. It handles business logic of what a user is doing, what he can do, etc. The user can create his own shirt for purchase. Service B is a data aggregator that contains a lot of the inventory and what's available.

The user starts creating a shirt, so service A request from service B, what styles/colors are available. Service B sends down a list of possible choices which service A then displays for the user. The user then selects one, customizes it and moves on to a new shirt. Again service A has to request from service B, what styles/colors are available.

Now let's assume within a life cycle of a user session, these styles/colors won't change and we know this is going to be the same data being retrieved over and over again. Not by just this user, but all users. So in this case, since the styles/colors are really part of Service B's domain, they should stay there and live there, or would it be advised to prevent all these needless calls and upon the first request (temporarily) save in Service A the data for the lifecycle of the session to prevent chatty services.

This is an over-simplified example but the problem remains real-world. Which is more suggested way of architecting this design? This usually applies for example when some fairly-static data is passing through some service, and this service will need this data again a few times within the lifecycle of these transactions. So I'm unsure whether the service should just save it temporarily for the life-cycle knowing the data won't change or not caring if it changes within the lifecycle or opt for more chatty services and keep requesting every time.

Answer 1

There is a different solution that "side-steps" this trade-off.

Your question suggests that you are thinking more in the "old" "service-oriented" approach. That is, services are basically data-oriented services that supply data. Like "Inventory", "Session", "Customer", etc.

An alternative approach would be, and this is quite similar to DDD bounded contexts, to decompose the application based on business areas. This results in a completely different architecture, in which data is not separated from the functions that work on it. Kinda like Object-Orientation.

This would result in the Shirt-Configurator having its own database with all the relevant information, including sessions, inventory, whatever. Also, including UI.

Another application could be the Checkout. The checkout could be a completely independent application, with only getting URLs back to the Shirt-Configurator for getting a proper presentation. The Checkout application would not have to call or even know the Shirt-Configurator.

And so on...

More on this style of architectures: http://scs-architecture.org/