Sticky sessions vs a shared session store vs JWTs: an interactive simulator

Once a user logs in, every later request has to say who they are. The session can live in the memory of the server that logged them in, with the load balancer pinning the user there (sticky sessions); in a shared store such as Redis that every server reads; or in a signed token such as a JWT that the client sends back and any server can verify. Each one fails in a different place.

The playground runs the same fleet through five events in order. Step through them and watch which approach loses sessions, which one stops serving, and which one cannot take a session back.

What each approach costs

• Sticky sessions need no extra infrastructure and no lookup, but the server is no longer disposable. Scaling out from 4 to 6 servers leaves the existing users where they are, so the old servers keep 100 users each while the new ones get 60. A restart for a deploy logs out every user on that server, here 100 of them, and afterwards the busiest server carries 43% more than the average.
• A shared session store makes the web servers stateless: new servers take a fair share at once and restarts lose nothing. The price is a network lookup on every request and a dependency on the store. If it is down, nobody can be authenticated: here all 520 users fail for the 30 s it takes to promote a replica.
• A signed token needs no lookup at all, only a signature check, and survives both the restart and the store outage. But the server cannot forget a token it has signed. A stolen token works until it expires, up to 60 minutes here, and so does a token for a user who was just banned or whose role changed. Tokens are also bigger: about 800 bytes on every request instead of a 40-byte session ID.

What real systems do

• Short access tokens with refresh tokens. An access token valid for 5 to 15 minutes is verified without a lookup; the long-lived refresh token is checked against a store when it is exchanged, so revoking it takes effect within minutes.
• Make the store highly available. A Redis primary with replicas and automatic failover, with sessions spread across shards, means one failed node stalls a fraction of users for seconds rather than everyone.
• Use stickiness as an optimization, not for correctness. Pinning users to a server can keep caches warm, but if losing the pin only costs a cache miss, servers stay disposable.
• Drain before restarting. If sessions do live on servers, stop sending new users to a server and wait for its sessions to end before a deploy.

The two designs on the wire

# shared session store: the cookie is only an ID
Set-Cookie: sid=9f2c7e41a0; HttpOnly; Secure; SameSite=Lax
GET sess:9f2c7e41a0 -> {user: 812, roles: [buyer], exp: ...}   # Redis, every request
DEL sess:9f2c7e41a0                                            # logout or revoke: gone at once

# signed token: the cookie is the session
Set-Cookie: at=eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiI4MTIiLCJleHAiOjE3...; HttpOnly; Secure
verify(signature, public_key) and exp > now                    # no lookup
# revoke: wait for exp, or check a deny list of token IDs (a lookup again)
# common middle ground: a 5 to 15 minute access token plus a refresh token checked in a store

In a system design interview

When the design has logged-in users, say where the session lives: “Web servers are stateless. The client holds a short-lived signed access token, which every service can verify locally, and a refresh token that the auth service checks in Redis, so logout and bans take effect within the access token’s lifetime. No sticky sessions, so we can autoscale and deploy without logging anyone out.” Expect the follow-ups: how to revoke a token immediately, what happens when the store is down, and how WebSocket connections, which are sticky by nature, fit in.

Read the guide to JWTs vs session cookies or stateful vs stateless services, see load balancing algorithms, or watch a strong candidate design a URL shortener.

Questions people ask