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/

Answer 2

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?

I hate to say this but it depends. It depends on your business requirements. It depends on if you want to have a rezilient system or not. How do you want service A to behave if service B is not available? You have two choises:

1. You want Service A to refuse working as it can't get the fresh data from service B. You do this if the data changes a lot or the data used in service A must be super-fresh all the time.

2. You want Service A to keep working, possibly by notifying the user that the data might not be fresh. In this case you should duplicate the data from service B to service A, by listening to events or by caching.

Answer 3

I must commend you for the finely-written question, but of course the answer would depend greatly on the business logic you're dealing with. This question is related to that of eventual-consistency (a property offered by some no-sql databases - like Couchbase).

Ultimately, its a question of tradeoffs: the 'cost' of retrieving the freshest data vs. the cost of using somewhat stale data that's readily available.

a few things factor in:

• how often the data updates?

• and more importantly, what happens (business-logic-wise) when you use stale data. Is it even acceptable to your users/apps?

• what would be the impact on your system to fetch fresh data every time? what's the infrastructure cost of doing that (in machines/money) and what's the latency it would incur?