Problem
We have multiple microservices, like Home, Menu & Cart, exposed via Gateway. Each one has API exposed to the app. Now, each API has certain information that is needed by the successive API. Wanted to know the best way to persist this information.
Possible Solution 1
One solution that comes to mind is to give the client(App in this case) the responsibility to share this information, given in the response of the current API, to the following API call. The app interacts via contracts and hence these are always bound via contracts.
Downside
Backward compatibility of the client is hard to achieve as it will need to add new params to the contract & new release is needed every time.
Possible Solution 2
Creating a session microservice, which holds contextual information of each API. Each API will ping this service for information. Since it will be an S2S call, contracts will be honored. App involvement will also be removed.
Downside
Creating a service looks like an overkill
Possible Solution 3
Each service maintains information about its own sessions. Every successive API fetches information of the previous sessions via S2S calls & works accordingly.
Downside
Doesn’t look like good practise.
4
Since software architecture is very contextual, it’s hard to answer confidently without more details.
However, one possible solution to this problem could be using a shared cache or database that all microservices can access. Each microservice can store and retrieve the necessary information without relying on the client or creating a separate session microservice. This approach would also avoid the downsides of the other solutions you mentioned, such as the need for backward compatibility with the client or the potential overkill of creating a new session service.
This is a simpler version of solution 2.