We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A user logs into an e-commerce site, adds items to their cart, and clicks checkout. The page reloads. They are logged out. Cart empty. They log in again, re-add items, and this time checkout works. The next day, the same thing happens at random.
The root cause: the application ran on four servers behind a round-robin . Session data was stored in memory on whichever server handled the login request. When the next request landed on a different server, that server had no record of the session. The user's login existed on server 2, but the checkout request went to server 3.
This is the core problem of distributed session management. When your application runs on more than one server, you have to decide where session state lives. The answer shapes your availability, scalability, and recovery characteristics.
| Strategy | How It Works | Durability | Scalability | |
|---|---|---|---|---|
| Sticky sessions | pins user to one server via cookie or IP hash | None added | Lost on server crash | Limited (hot servers) |
| Centralized store () | All servers read/write sessions to shared Redis | +1ms per request | Survives server crashes | Horizontal (Redis Cluster) |
| Database-backed | Sessions stored in PostgreSQL or MySQL | +5-20ms per request | Full durability | Vertical (DB bottleneck) |
| tokens | Session data encoded in signed token, no server storage | None added | N/A (stateless) | Infinite (no server state) |
| Encrypted cookies | Session data encrypted in cookie itself | None added | N/A (client-held) | Infinite, but 4KB cookie limit |
Redis is the production standard. Shopify, GitHub, Slack, and most Rails/Django/Express apps use Redis for sessions. Sub-millisecond reads, native for expiration, and straightforward replication. The cost is one more piece of infrastructure to operate, but the trade is worth it.
JWTs trade revocation for statelessness. A JWT is self-contained. The server does not store anything. But that means the server cannot revoke a specific JWT before it expires. To revoke, you need a blocklist, which reintroduces server-side state. Short-lived access tokens (5-15 minutes) plus longer-lived refresh tokens (7-30 days) is the standard pattern. Stripe, Auth0, and Firebase all use this approach.
When NOT to use sticky sessions: if you need high availability. When the pinned server crashes, every user pinned to it loses their session simultaneously. A fleet of 10 servers means each crash affects 10% of active users. The thundering herd of re-authentications can cascade into further failures.