The textbook rule is "make your servers stateless so any request can go to any node." It's good advice — until you're paying to rebuild expensive per-user state on every request. Sticky sessions (also called session affinity) route all requests from a given client to the same backend node, so that node can keep cached or in-memory state for that user.

The load balancer picks a node on the first request and "pins" subsequent requests to it, usually via a cookie (JSESSIONID, AWSALB) or a hash of the client IP. AWS ALB, NGINX (ip_hash or sticky cookie), and HAProxy all support this natively.

When stickiness earns its keep:

• WebSocket and SSE connections — the connection is the state. Reconnecting to a different node means re-authenticating and re-subscribing.
• Expensive per-user warmup — ML feature vectors, decrypted secrets, compiled query plans, hydrated permission graphs. A real-world example: a SaaS analytics app loaded ~40MB of denormalized org metadata per user on first request (300ms). With round-robin routing, every fifth request hit a cold node. Sticky cookies dropped p99 latency from 380ms to 95ms — at the cost of slightly uneven CPU distribution.
• In-process caches you can't easily externalize — when moving to Redis would add a network hop that defeats the purpose.

What it costs you:

• Uneven load. A few "whale" users can pin disproportionate work to one node.
• Deploys get awkward. Draining a node forces every pinned session to rebuild state elsewhere — exactly what stickiness was avoiding. You'll want graceful drain windows.
• Autoscaling lies to you. Adding nodes doesn't relieve existing hot nodes; only new sessions land on them.
• Failover is harder. When a sticky node dies, those users hit a cold cache and may lose in-memory work.

Rule of thumb: if the cost of rebuilding per-user state on a cold node exceeds ~50ms and that state is requested more than once per minute per user, stickiness is probably worth it. Below that threshold, the cache-miss tax is cheaper than the operational complexity stickiness adds.

Hybrid approach that usually wins: use sticky sessions as a performance optimization, not a correctness requirement. Keep authoritative state in Redis or the database. Treat the in-memory copy as a cache that any node could rebuild. Now you get the latency win without the failover nightmare — losing a node degrades performance for affected users, but doesn't break them.