Stateless servers vs sticky sessions

The decision

A session is a record that says who a logged-in user is. When you run many servers, you must decide where that record lives. Servers are stateless when they keep nothing between two requests, so any server can answer any request. The session sits in a shared store, or inside a signed cookie, which carries a signature so the user cannot change it. With sticky sessions, the load balancer sends each user to the same server every time, and that server keeps the session in its own memory.

Choose stateless when

• You will add and remove servers during the day, or deploy often.
• One server failing must not log users out.
• You want the load shared evenly, with no user pinned to one server.

Choose sticky sessions when

• The connection itself is long-lived and tied to one server, such as a WebSocket. The server holds that connection anyway.
• The server holds large state that is costly to rebuild, such as a live game room.
• You run a small, fixed number of servers, and you need a quick bridge while you build a shared store.

The numbers that change the answer

Assumptions: 500,000 users are logged in at the peak. A session is 1 KB. The peak is 20,000 requests per second. A 4-core server takes 350 requests per second at 70% busy.

Why sessions in memory fail. Requests spread evenly over N servers. The chance that the next request goes to another server is (N - 1) / N. That is 3 / 4 = 75% for 4 servers, and 57 / 58 = 98.3% for 58. Adding servers makes it worse.

What each choice costs at this load.

• Sticky, one server stops: 500,000 / 58 = 8,621 users lose their session. With 4 servers it would be 500,000 / 4 = 125,000.
• Sticky and scale-in: the peak ends and the fleet shrinks from 58 to 6 servers. That removes 52 servers, so up to 52 / 58 = 90% of logged-in users lose their session. Every day.
• Shared store: 20,000 lookups per second. Assumption: the store takes 100,000 operations per second, so this is 20%. The sessions take 500,000 x 1 KB = 500 MB, which fits in memory. Assumption: each lookup adds 0.5 ms.
• Signed cookie: each request carries 1 KB more. 20,000 x 1 KB = 20 MB per second, which is 160 megabits per second more traffic. A browser should support at least 4,096 bytes per cookie (see Sources), so the session must stay small. The user can read the cookie, so keep secrets out of it.

Uneven load with sticky by IP address. Assumption: 50,000 users sit behind one phone-company address, and each sends 1 request every 10 seconds. That is 50,000 / 10 = 5,000 requests per second to one server. 5,000 / 350 = 14.3 times what it can take. Sticky by cookie spreads new users better, but cannot move users away from a busy server.

What breaks with each choice

• Stateless with a shared store: the store becomes a single point of failure and adds a hop. Fix: run the store with a copy that takes over. If it is down, ask users to log in again.
• Stateless with a signed cookie: you cannot cancel one session at once, because the cookie holds everything. Fix: a short life, plus a small list of cancelled sessions.
• Sticky: uneven load, lost sessions on every stop, deploy or scale-in, and extra care in the load balancer. Fix: move the session out to a shared store.

What it costs

• Sticky costs nothing to start. The price comes later, at each deploy and each scale-in.
• A shared store is one more system to run. Assumption: 1 to 2 engineer-weeks to add, and 1 to 2 engineer-days a month to run.
• You can begin with sticky and add the store later, if you wrote the session code behind one small interface.

How each level answers

SDE-1: A stateless server keeps nothing between requests. Sticky sessions send a user to the same server each time.

SDE-2: I keep servers stateless and put sessions in a shared store. Then any server can answer, and I can add or remove servers at any time. I use sticky only for long connections, like a WebSocket.

Senior: With 58 servers, 98.3% of requests would reach a server without the session, so I need a shared store or a signed cookie. At 20,000 lookups per second the store runs at 20% of an assumed limit. Sticky would log out 8,621 users when one server stops. The failure to watch is the store going down, and the fallback is to ask users to sign in again.

Staff: Statelessness lets the business deploy at any hour and scale for a sale day without logging customers out. I treat sticky as a bridge with an end date. I migrate by writing sessions to both places, reading from the store, then turning sticky off. The platform team owns the store and its uptime. I measure forced logouts per deploy, which should be 0. I also track p99 (the time within which 99 of 100 requests finish) latency of the lookup.

Say it in the interview

"I keep servers stateless and put sessions in a shared store, because with 58 servers 98.3% of requests would reach a server without the session. The store takes 20,000 lookups per second, 20% of its limit, and adds 0.5 ms. I use sticky sessions only for long connections like WebSockets."

Common mistakes

• Saying "sticky sessions fix the problem". They hide it. A server stop, a deploy or a scale-in still logs users out.
• Putting large data in a signed cookie. Browsers only have to support 4,096 bytes per cookie, and the cookie travels with every request.
• Forgetting the store is now critical. If it fails, every user is logged out, so it needs a copy that takes over.

Sources

• Cookie size: RFC 6265, section 6.1, says user agents should support at least 4,096 bytes per cookie. https://www.rfc-editor.org/rfc/rfc6265.html (opens in a new tab) (checked 26 Oct 2026).
• The user counts, session size, request rates, store speed, added latency, the shared address example and the effort are assumptions made for teaching. The arithmetic is calculated from them.