Module 3 · Serving More People, Faster · Lesson 9 of 35
Stateless vs stateful architecture: where your data waits between taps
11 minFree System design course · Beginner to intermediateLesson 3.2By Saket Bhatnagar
Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.
In short
- Stateless vs stateful architecture is about where a server keeps what it remembers. A stateful server keeps users in its own memory; a stateless one looks them up.
- Logins and seats set aside for a payment move to one shared place; bookings and payments stay in the database.
- Then any server can serve anyone: add, restart or lose one, and users carry on.
Video lesson · coming soon
Stateless vs stateful: where your data waits between taps
Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.
- 01 The app that forgets Meera
- 02 Railway counters, one central system
- 03 Thin servers, one thick state layer
- 04 Pick a home for each piece of data
- 05 The Friday fix, before and after
- 06 Mark where your memory lives
Arjun has four SeatJaldi servers on the test site. He logs in, taps Seats, and is asked to log in again. Two taps later it asks once more.
Meera tries on her phone. Same password, same app, and every few taps SeatJaldi has never heard of her. She picks seat A12, goes to pay, and the seat is no longer hers.
On Friday evening Arjun puts out a small fix, and every user is thrown back to the login screen. Meera asks, “Where did my login go? Why does it forget me only on some taps?”
What is the difference between stateless vs stateful architecture?
A stateful server remembers each user in its own memory between requests; a stateless server remembers nothing between requests and looks everything up.
- The rule: keep the servers forgetful and keep state in one shared place.
- The picture: thin, identical servers above one thick layer that holds the state.
You have seen a travel site ask you to log in again after one tap, then let you in on a refresh. Your login lived in one server’s memory, and the refresh reached that server.
You have seen an app update log everyone out. The update restarted the servers, and a restart empties their memory.
Why does Arjun get logged out at random?
You saw the cause in lesson 8: his login sat in the memory of one server, and his next tap went to another. Now look at exactly what each server knows. It is the clerk at window 4, hearing “no booking found”.
Tap 1: log in
Server 2 checks the password and keeps Arjun’s session in its memory.
Tap 2: open Seats
It reaches server 4, which has no session for Arjun: login screen.
Tap 3: log in again
Server 4 now keeps its own session. Two servers remember Arjun separately.
Tap 4: pick a seat
This reaches server 1, which has never met him. Login screen again.
The fix: take the notepads away, so every server saves and reads sessions in one central place.
Meera’s seat A12 vanished the same way. Server 2 kept it aside in its memory, and her payment tap reached server 1.
Thin servers above one thick state layer
Drag to explorePhones send requests to four identical servers that remember nothing. Below them, a session store holds logins and seat holds; the database holds bookings and payments.
Diagram connections:
- Phones to Four servers (Any request)
- Four servers to Session store (Look up session)
- Four servers to Database (Save bookings)
- Phones: Any tap can reach any server.
- Four servers: Stateless: any copy can answer any request.
- Session store: State layer: logins and seat holds shared by every server.
- Database: State layer: bookings and payments that must never be lost.
Where should each kind of state live?
Short-lived state about one user goes in the session store. What must never be lost goes in the database; what only the user needs stays on the phone. At the station: the central system holds today’s bookings, the records room keeps paid tickets, and your slip carries the rest.
What just happened? Three questions picked each home: is it about one user, how long must it last, and does every server need it?
One exception: a setting the same for everyone, like an on/off switch for a new seat map, may be copied into each server at start. No user gets lost; a change needs a reload.
How do you make a server stateless in practice?
You move all per-user memory out of the server. A cookie, a small note the app stores and sends with every request, carries only a long random session id. The session store holds the rest.
A signed token, a note the server stamps so nobody can forge it, can carry the data with no store. But it is hard to cancel early, say after a phone is lost.
def get_user(request, session_store):
session_id = request.cookies.get("session_id")
if not session_id:
return None # no id: ask the user to log in
user_id = session_store.get(session_id) # None if missing or expired
if user_id is not None:
session_store.set(session_id, user_id, ttl_seconds=1800) # renew: 30 idle minutes
return user_id
def hold_seat(session_store, match_id, seat_code, user_id):
key = f"hold:{match_id}:{seat_code}"
session_store.set(key, user_id, ttl_seconds=600) # 10 minutes
return keyWhat just happened? The server keeps nothing between calls. The id arrives with each request, and each good tap renews the 30-minute expiry. This plain set overwrites an earlier hold; a later lesson makes holds safe.
Give each session a TTL, a time limit, renewed on each tap: say 30 idle minutes (an assumption). OWASP lists 15 to 30 minutes as common for low-risk apps, and 2 to 5 for high-value ones.
Also set a hard limit that taps do not extend, and issue a fresh session id at every login. Expiry is why a long form can say “your session has expired”.
How big is the store? Say each session is about 1 KB, roughly a thousand letters (an assumption). All 1 lakh daily users logged in at once: 1,00,000 × 1 KB = about 100 MB (1 MB is a thousand KB). One machine holds that.
A shortcut is to always send Arjun to server 2, like “always go to window 3”.
- Sticky sessions hide the problem: when window 3 closes, its notepad goes too.
- Busy users pile load on one server, and a restart loses its sessions and seat holds.
With stateless servers, a deploy is boring. Take one of four out, and the other three keep serving if they can carry the traffic. Each finishes its open taps, restarts and rejoins, like a new rulebook reaching one window at a time.
The honest limit: the state layer is now the shared part. It is the next thing to run out and, while on one machine, the next single point of failure.
Try it yourself
List what your app remembers
Write everything kept between two taps: login, cart, uploads, counters, settings.
Ask three questions
Is it about one user? How long must it last? Does every server need it?
Give each a home
Phone, session store, database, or “same for everyone, copy at start”.
Check your work
Nothing lives in “memory of one server”, and money is in the database. Compare with the table below.
| Item | Must it last for good? | Home |
|---|---|---|
| Login | No, log in again | Session store |
| Seat hold | No, it expires | Session store, with a timer |
| Cart on this phone | No | Phone |
| Payment status | Yes | Database |
| On/off switch, same for all | Yes | Each server loads it from the database |
Back at the test site, Arjun can name it: each server was stateful. Meera’s login sat in server 2’s memory. Her taps that reached server 2 worked; the ones that reached server 3 found nothing.
He moves sessions and seat holds to the session store; bookings and payments stay in the database. The next Friday fix logs nobody out.
Meera taps, pays, and seat A12 is still hers. Any window can serve her now. Then she asks, “Any server can take any request now. Who decides which server gets which request, and what if one dies?”
Check yourself
Check yourself
After logins move to the session store, Arjun restarts server 2. What happens to its recent users?
Pick an answer to see why it is right or wrong.
Check yourself
A teammate says, “Stateless means the app cannot save anything.” What is the best reply?
Pick an answer to see why it is right or wrong.
Check yourself
A sticky session sends Arjun to the same server every time. What is the main cost?
Pick an answer to see why it is right or wrong.
Remember these three
- Keep the servers forgetful and keep state in one shared place.
- Sessions and seat holds go in the session store with an expiry; money goes in the database.
- Sticky sessions hide the problem; a restart still loses what that server remembered.
Questions people ask
- What is a stateless server?
- A stateless server remembers nothing between requests, so any copy can answer any request. What it needs comes with the request or waits in a shared place.
- Where should I store user sessions?
- Store sessions in a fast session store that every server can reach, with an expiry that renews on each tap. Keep only a random session id on the phone.
- Are sticky sessions bad?
- Sticky sessions are a short-term patch, not a disaster. They lose sessions when a server restarts and can overload one server, so a session store is better.