You will also receive a link to this document at the email address you provided. Browse additional resources from our library of Case Studies, Benchmarks, and more!
Simply put, a session store is a chunk of data that connects a user to a service. It is stored separate from the primary database in order to provide stickiness without direct, constant access to the database. A user could be a visitor to a website, an account on a phone app, or even another service that accesses data via an API.
Sessions often persist between requests through a cookie. The service gives the client the cookie, the client stores it, then sends a subsequent request back with the cookie. The server then uses the cookie string as a token for data associated with the user.
Session stores are crucial for holding user data, but they aren’t always able to meet the industry’s rigorous data processing standards on their own. If traffic increases to the point where the server begins to struggle, a company may add more servers, with a load balancer to ensure that each server equally manages incoming traffic. But what happens if a user is directed to a different server than the one from initial log in? Their session data would be stored on the first server, and the second server would not recognize them.
In this paper we will explore session stores that move beyond “dumb” stores of data.
In addition to presenting an alternative to a monolithic application framework, microservices can make session stores more intelligent, and enable them to perform more advanced processing.
Microservices are certainly not required for all session stores, but if your company wants to tailor its hardware and infrastructure to more complex use cases, accommodate increasing traffic to its servers or implement data storage for more than the most basic user data, this paper explains the ideal solution. To find out more about how microservices can improve session stores, and how Redis can help you seamlessly switch to microservices, please download our paper.