Failure
- With in-memory sessions, login state exists only on the server that processed the login. If the load balancer sends the next request elsewhere, that server treats the user as logged out.
7:54 8:56 9:29
- With three servers and state stored on only one, roughly two out of three later requests can reach a server that does not know the user.
9:29
Session mechanics
- After checking credentials, the server creates a session record and gives the browser a random session ID. The browser sends that ID with later requests so the server can identify the user.
8:25
Fix
- Move session records out of app memory and into a shared store that every server can read and write. Any instance can then handle any request.
10:00 10:36
- A server is stateless when it keeps no user-specific information between requests. Redis is a common shared in-memory store for sessions because session lookup happens on every authenticated request.
10:36 11:12
sequenceDiagram
participant B as Browser
participant L as Load balancer
participant A as App server A
participant R as Shared session store
participant C as App server B
B->>L: Login
L->>A: Route request
A->>R: Save session
A-->>B: Return session ID
B->>L: Next request plus session ID
L->>C: Route request
C->>R: Read session
C-->>B: Authenticated response
Cost
- Every authenticated request gains a network lookup. The shared store is also a dependency whose outage can prevent all users from being recognized as logged in.
11:39