Explained Simply #20
Statelessness and why it helps scale
In Part 13, we met stateless and stateful designs. REST makes statelessness one of its core rules. Each request must carry everything the server needs to handle it. The server doesn’t keep notes about the client from one request to the next.
That sounds like a limitation at first. In practice, it’s what lets a popular API serve enormous numbers of requests without falling over.
Our running example is the travel app. Once it gets popular, a single server can’t handle all the traffic. The team needs to understand why statelessness matters before they can scale.
Everyday comparison: Think of a help desk with many staff. If each request arrives with a full explanation and a reference number, any staff member can handle it, and the queue moves quickly. If only one specific person remembers your problem, you wait for that person every time, even when others are free. Statelessness means every staff member can take any request.
The problem that statelessness solves
Imagine the travel app runs on one server. Every login, every search and every booking goes to it. That works until the traffic grows.
The team adds two more copies of the server and places a load balancer in front. A load balancer is a machine that receives every request and passes it to one of the copies. It spreads the work evenly.
Now suppose a user logs in. The login is stored in the memory of Server A. The user’s next request is passed by the load balancer to Server B. Server B has never heard of this user, so the app behaves as though the user has logged out. The user is confused, and the team is confused too.
How a carried token avoids the problem
A stateless design avoids this completely. When the user logs in, the server returns a token, a signed piece of data that proves who the user is. The app sends that token with every request, usually in the Authorization header.
Now any server can check the token. Server A, Server B and Server C all use the same check. A request can land on any of them, and nothing breaks. You can add a fourth server tomorrow without copying anybody’s login into it.
The token is not a magic key, though. It needs a valid signature, an expiry time and a secure way to travel, which we’ll cover in the security part of the series. The point here is that the proof comes with the request, so no particular server has to remember you.
Stored sessions can work, but with conditions
Stored sessions aren’t impossible in a scaled system. There are two common approaches.
One is a shared session store, such as a fast database that every server can read. Each server looks up the session in that central place. This works well, but the shared store becomes a new component you must keep running and healthy.
The other is sticky routing, where the load balancer always sends the same user to the same server. This is simpler to set up, but it reduces the benefit of spreading load, and it fails when that server goes down.
Both approaches add moving parts. Statelessness avoids them by design.
Get ThinkTaught’s stories in your inbox
Join Medium for free to get updates from this writer.
What else statelessness makes easier
Scaling out is the headline benefit, but the same idea brings several others.
Restarts become safe. If a server is restarted, for an update or a crash, no user loses their place, because nothing important lived only in that server’s memory.
Caching works better. When the same request always produces the same answer for the same inputs, a cache can store that answer and serve it without asking the server again.
Testing is simpler. Each request explains itself, so you can test it on its own, without first setting up a long chain of earlier requests.
A common misunderstanding
Statelessness does not mean the server stores nothing. The travel app still stores trips, bookings and users in a database. The key point is that the server doesn’t remember which request came from which client between calls. Each request brings the proof it needs, and the database holds the actual data, which every server can reach.
So the stateless rule applies to the conversation, not to the data. Data lives in the database, and the conversation’s context travels with each request.
Where statelessness is not the whole story
Real systems often mix approaches. A shopping cart in progress might be stored in a shared cache, and a long-running video upload might keep state while it runs. Those choices are fine, as long as the state is deliberate and stored somewhere every server can reach. The goal is to avoid hidden memory that only one machine holds.
Quick recap
- REST requires each request to carry what the server needs.
- A stateless server keeps no memory of the client between requests.
- Carried tokens let any server answer any request, which helps scaling.
- Stored sessions need a shared store or sticky routing, which add complexity.
- Statelessness also makes restarts, caching and testing simpler.
- Data still lives in a database. Only the conversation’s context is stateless.
One question to take with you
Now that each request stands alone, some requests can be repeated safely and others can’t. If a request times out, can you send it again? That depends on the method, and it’s the next topic.
That’s what the next episode answers: Safe and idempotent methods.
Follow ThinkTaught so you don’t miss it. If something here is unclear, tell me in the comments. We’re learning this together
