Session, State & Lock Management In MicroServices
Traditional Simple Approach
Whenever we talk of distributed transaction spread over multiple microservices, gains are independence, autonomy, scalability and what not.
While we gain benefits, what are the challenges when moved from monolith.
Monolith has a single block/application and working with a single database hence doing state management, session management , lock management is fairly simple.
When it comes to microservices i.e. with distributed transaction how do we achieve these things.
Since microservices are independent and have their own persistence and deployed on multiple & various instances, managing session on a single database or locally is not possible. This leads to the need of externalizing the storage i.e. for session, state and lock management as well.
This externalized storage is then accessed by the respective services.
As soon as the transaction hits the ecosystem or lets consider an API gateway, then API gateway along with authentication would create a unique identifier and propagate through all subsequent microservices used. All the microservices can then get the required data from session using the unique identifier.
Typically individual service would have its own state during the lifetime of the API call.
A user interaction or a complete function to be served would be entertained in a session.
Lock management is needed when the same data can be mutated resulting into a corrupt or incorrect data. Thus the thread or service instance which is acting on a session object it would acquire lock and then mutate it.
This typically requires a record to have quick write read ability with temporary life.
When it comes to session management, historically there are two aspects which has helped in this endeavor.
- Sessions which are typically stored on the disk, or are in memory or written to a database.
There are ways to address cookie sharing across server and domains. For our purpose, within the same domain cookies can be shared.
With respect to session, that can be associated with unique identifier and then can be stored in the distributed database store.
Application can consume the data. There are multiple patterns. First, one application writes and then all other applications read and execute respective operations by reading the data. Second, applications keep adding information to existing session and the next application consumes that information and builds on top of that.
Concluding application plays the last stroke.
Redis can be used for such a mechanism. Few comparison are given as below.
|What is it?||Redis is an open source, in-memory data structure store, used as a database, cache and message broker.||MongoDB is a free and open-source cross-platform document-oriented database program.||Couchbase Server, is an open-source, distributed multi-model NoSQL document-oriented database software package that is optimized for interactive applications.||RavenDB is an open-source Document Database written in .NET.|
|Peak Response time||1||3||2||4|
1 is the best score and 4 is the least score in the comparison.
Comparison denotes Redis as the winner.