Why a session store exists
After a user logs in, the server needs to remember them on later requests. A session store keeps that login state on the server, keyed by a random session id that the browser carries in a cookie.
On each request the server looks up the id, finds the session record, and learns who the user is and what they may do. Because the record lives server side, the cookie itself can be a meaningless opaque string.
What goes in a session
- The user id the session belongs to.
- A creation time and an expiry so old sessions die.
- Optional context like roles, device, or last activity.
Picking the storage
- An in memory store is fast but loses everything on restart and does not share across nodes.
- A shared store like a key value cache lets any server read the same session, which is what you need behind a load balancer.
The store must support fast lookup and a time to live so expired sessions are evicted automatically.
Key idea
A session store keeps login state on the server keyed by an opaque id so any request can resolve the caller and revoke access instantly.