Session & State Issues in Load-Balanced Environments

Web & Application Troubleshooting

Chapter 5 · Session & State Issues in Load-Balanced Environments

Spread traffic across several application servers behind a load balancer, and a real question appears that a single-server setup never has to ask: where does a logged-in user's session actually live? If each server only keeps sessions in its own local memory, a session exists on exactly one server — whichever one happened to handle the login. This chapter is about what happens when a later request lands somewhere else.

Sticky Sessions (Session Affinity)

One fix: configure the load balancer to route every request from a given user consistently to the same backend server, usually via a cookie identifying which server they were first assigned to. It solves the local-memory problem without needing any shared infrastructure — but it has a genuine, honest failure mode of its own.

Sticky sessions concentrate risk on one server
Every user stuck to a given server has all of their session state living only there. If that one server goes down, gets restarted, or is removed during a deployment or a scaling event, every session assigned to it is lost simultaneously — not gradually, not one user at a time, but all at once, for whichever users happened to be routed there.

Shared Session Stores

The more resilient alternative: store session data in a shared, external store — commonly Redis — that every application server can read from and write to, regardless of which one a given request lands on. Any server can now correctly serve any user, removing the single-server session-loss risk sticky sessions carry.

Not a strictly better, no-downsides fix
A shared session store introduces its own dependency and its own failure mode: if the shared store itself becomes unavailable, every session everywhere fails at once — a different, and arguably more severe, single point of failure than losing sessions on one backend server. It also adds a real network round-trip to every session read and write, where a local-memory lookup had none. Neither approach is simply "better" — each accepts a different kind of risk.

Recognizing the Symptom Pattern

"Logged out randomly," "my cart emptied," or "had to log in again mid-session" — reported by some users but not others, especially clustering around a recent deployment or scaling event — is the classic tell. Worth being precise about how this differs from Chapters 3 and 4's own "some requests fail" patterns: there, the "some" correlated with timing and resource contention. Here, the "some" correlates with which server a user happens to be routed to — a genuinely different kind of "intermittent," worth telling apart before assuming the same category of cause applies again.

A Practical Diagnostic Check

Two things worth checking directly: whether the timing lines up with a deployment or scaling event (the same "does it correlate with a known event" question from Chapter 1, applied here), and whether the sticky-session cookie is actually present and being honored.

$ curl -v https://app.example.com/login ... < Set-Cookie: AWSALB=xyz123...; Path=/ < Set-Cookie: session_id=abc987...; Path=/; HttpOnly

A missing or unexpectedly absent affinity cookie — stripped by a misconfigured proxy or CDN somewhere in the path, or a load balancer configuration change — would explain session loss just as directly as a server restart would.

Working Example: The Scaling Event That Reshuffled Sessions

A fresh ticket: since yesterday's autoscaling event added two new server instances, roughly 15% of users report being logged out mid-session, seemingly at random. Investigating confirms sticky sessions are configured — but the application was never using a shared session store, only local, per-server memory. Users who happened to remain assigned to the original server instances continued fine. But many load balancers redistribute existing connections across the new, larger pool of backends when the pool itself changes — exactly what happened here, reshuffling a portion of users onto instances that had never seen their session before. Their local-only session simply didn't exist on the new server, and they were silently logged out.

The fix isn't reverting the scaling event — it's migrating to a shared, Redis-backed session store, so a scaling event (or any future one) no longer has the power to erase sessions just by changing which server happens to answer a given request.

Hands-On Exercises

Exercise 1

Explain why sticky sessions solve the local-session problem without needing shared infrastructure, and what genuine failure mode they introduce in exchange.

📄 View solution
Exercise 2

Explain why this chapter says a shared Redis-backed session store isn't simply a strictly better fix than sticky sessions, even though it solves the single-server session-loss problem.

📄 View solution
Exercise 3

In this chapter's worked example, explain why the autoscaling event specifically caused session loss for some users, even though sticky sessions were correctly configured.

📄 View solution

Chapter 5 Quick Reference

  • Local, per-server sessions only work if every request from a user lands on the same server — sticky sessions enforce that via a routing cookie
  • Sticky sessions concentrate risk: losing one server loses every session assigned to it, all at once
  • A shared session store (e.g. Redis) removes that risk but adds its own dependency and a network round-trip per session access
  • "Logged out randomly" correlating with a deployment or scaling event is the classic session-affinity symptom — a genuinely different kind of "intermittent" than Chapters 3–4's own resource-contention patterns
  • Check for the sticky-session cookie directly (curl -v) — a missing one explains session loss just as directly as a server going down
  • Next chapter: Slow Query & N+1 Diagnosis