Stateless vs Stateful Web Tier

System Design FundamentalsMidsystem-design

The Question

What is the difference between a stateless and stateful web tier?

What a Strong Answer Covers

• sessions in Redis
• "horizontal scaling
• "sticky sessions problem

Senior-Level Answer

**Stateful web tier**: each web server stores session data locally — in memory or on local disk. A user who authenticates on server A must always be routed back to server A because only that server holds their session. This is enforced via sticky sessions (load balancer affinity). Problems: if server A crashes, the session is lost; scaling horizontally requires either migrating sessions or dropping them; deployments that replace servers terminate sessions.

**Stateless web tier**: no session data lives on the web server. Every request carries all the context needed to process it — either in a token (JWT carries identity and claims) or by looking up shared state in an external store (Redis, Memcached, database). Any web server can handle any request from any user at any time.

**Why stateless is preferred at scale:** - Load balancers can distribute requests to any healthy instance — no sticky sessions - Auto-scaling is clean: add/remove instances without session migration - Rolling deployments work without session drainage delays - Simpler failover — crashed server is replaced transparently

**JWT approach**: the client stores a signed token. The server validates the signature on every request with no lookup. Tradeoff: tokens cannot be invalidated before expiry without a blocklist (which reintroduces shared state). Use short expiry + refresh token rotation.

**Shared session store approach**: sessions live in Redis. Web servers are stateless; Redis holds state. This allows immediate invalidation and richer session data. Redis becomes a stateful tier — it must be highly available with replication.

**In practice**, most production systems are stateless web tier + stateful data tier. The database and cache are inherently stateful; the compute layer is kept stateless. This separation is what allows horizontal scaling of web servers while maintaining data consistency.

The system design interview framing: when asked to scale a web app, moving from stateful to stateless is usually one of the first architectural changes to propose.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Claiming JWT is always better — not mentioning the revocation problem
• Forgetting that Redis/shared session store is itself stateful and must be HA
• Treating stateless as 'no state anywhere' — state moves to data tier, not disappears
• Not mentioning sticky sessions as the symptom of a stateful web tier

Follow-Up Questions

• How do you immediately invalidate a JWT before it expires? — Maintain a token blocklist (Redis set keyed by jti) — every request checks the blocklist. This reintroduces shared state.
• What happens to in-flight sessions during a deployment if you use sticky sessions? — You must drain the old instance (stop new traffic, wait for sessions to expire or migrate) before terminating it.
• Why is a shared Redis session store considered part of the stateful tier, not the stateless tier? — Redis holds mutable session state — it must be replicated and made HA. The web tier is stateless because it offloads state to Redis.
• How does a stateless design affect autoscaling behavior? — Scale-out is instantaneous — new instances start cold with no session state to warm; scale-in terminates instances without user impact.

Related Questions

• Redis Caching Patterns
• Vertical vs Horizontal Scaling
• API Versioning
• SLOs vs SLAs
• Availability — Five 9s