TL DR Should the service choose what it needs from time to time to store data in its local database, or request data each time from the service from which the data was received?
Let you have a general web store / order example application. Service A is a user session management service. It handles the business logic of what the user does, 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 inventory and available.
The user begins to create a shirt, so request service A from service B, which styles / colors are available. Service B sends a list of options that Service A then displays to the user. Then the user selects one, sets it up and moves on to a new shirt. Again, service A should request from service B which styles / colors are available.
Now suppose that during the life cycle of the user session these styles / colors will not change, and we know that this will be the same data that is retrieved again and again. Not only this user, but all users. Thus, in this case, since the styles / colors are indeed part of the Service B domain, they should stay there and live there, or it would be recommended to prevent all these unnecessary calls and, at the first request, (temporarily) save life cycle data in Service A Sessions to prevent chat services.
This is an overly simplified example, but the problem remains real. How is a more efficient way to develop this project proposed? This is usually applied, for example, when some fairly static data passes through some service, and this service will need this data repeatedly several times during the life cycle of these transactions. Therefore, I’m not sure that the service should simply temporarily save it for the life cycle, knowing that the data will not change or will not be taken care of if it changes during the life cycle or select more frequent services and continue to request each time.
source
share