Stateless
A system where each request contains all the information needed to process it. The server doesn't remember previous requests. Easier to scale horizontally.
What is Stateless?
In short
A stateless system is one where every request carries all the information the server needs to process it, so the server keeps no memory of earlier requests from the same client. Because any server can handle any request without prior context, stateless designs scale out easily by adding more identical machines behind a load balancer.
What stateless actually means
Stateless describes a server or service that treats each incoming request as completely independent. Nothing about the previous request is stored on the server between calls. If a request needs to know who you are, what's in your cart, or which page you were on, that information has to travel with the request itself, usually as a token, a cookie, or parameters in the body or URL.
The opposite is stateful, where the server holds on to data about your ongoing interaction in its own memory. A classic stateful pattern is storing a logged-in user's session in the server's RAM. The problem is that only that one server knows about your session, so every following request from you must go back to the same machine.
Stateless does not mean there is no state anywhere. State still exists, it just lives somewhere shared and external: a database, a cache like Redis, or a signed token the client holds. The server itself stays a clean, interchangeable worker that forgets you the moment it sends a response.
How it works under the hood
HTTP was designed to be stateless from the start. A browser opens a connection, sends GET /products, gets a response, and the server is free to forget the whole exchange. To layer identity on top of that, the request includes something self-contained. A common choice is a JSON Web Token (JWT): a signed blob the client stores and sends in the Authorization header on every request. The server verifies the signature and reads the user ID straight out of the token, no lookup of server memory required.
Because no server holds private session data, a load balancer can send your requests to any of 50 identical app servers and each one can answer correctly. This is why stateless services pair so well with horizontal scaling and auto-scaling groups. You can spin up a new instance, route traffic to it instantly, kill it later, and nobody loses their session.
The cost is moved elsewhere. Shared state goes to a database or a cache that all servers can reach, and that store becomes the thing you must scale and protect. With JWTs, you also accept larger requests (the token travels every time) and the headache of revoking a token before it expires, since the server is not tracking it.
When to use it and the trade-offs
Reach for stateless designs when you need to scale horizontally, deploy frequently, or survive servers dying without warning. REST APIs, serverless functions like AWS Lambda, and most modern web backends are stateless by default because cloud instances are cheap, disposable, and replaced often. If a server can vanish at any moment, you cannot afford to keep anything important only in its memory.
Stateless also makes failures cleaner. If one instance crashes mid-traffic, the load balancer just routes around it and users notice nothing, because the next server has everything it needs in the request. Rolling deploys and blue-green releases get much simpler for the same reason.
The trade-off is overhead and complexity pushed to other layers. Every request may re-send and re-verify the same auth token, and shared state in a database or cache adds a network hop and a new bottleneck. Some workloads are genuinely stateful by nature, such as a live multiplayer game tracking positions per tick or a long WebSocket connection, and forcing those to be stateless costs more than it saves.
A concrete example
Picture an e-commerce API running on 20 servers behind a load balancer. A user logs in and gets back a JWT signed with the server's secret key. From then on, every request the browser makes carries that token in the Authorization header.
When the user clicks Add to Cart, the request might land on server 7. Server 7 verifies the JWT, reads the user ID, and writes the cart item to a shared PostgreSQL database. The next click goes to server 14, which has never seen this user before, but it verifies the same token, reads the cart back from PostgreSQL, and works perfectly. No server ever needed to remember the user.
Now traffic spikes on Black Friday. The auto-scaling group adds 30 more servers in minutes, and they start handling requests immediately with zero warm-up, because there is no session data to copy over. That instant, painless scaling is the whole point of staying stateless.
Where it is used in production
AWS Lambda
Functions are stateless by design; each invocation gets a fresh context and persists anything it needs to S3, DynamoDB, or another store.
NGINX
As a reverse proxy and load balancer it spreads requests across stateless backend instances, since any instance can serve any request.
Redis
Commonly used as the external session store that lets web servers stay stateless while still sharing login state across the fleet.
Kubernetes
Its Deployment objects assume stateless pods that can be created and destroyed freely; truly stateful workloads need a separate StatefulSet.
Frequently asked questions
- Is HTTP stateless or stateful?
- HTTP itself is stateless. Each request is independent and the server is not required to remember previous ones. Cookies, sessions, and tokens are tricks layered on top to fake continuity, but the underlying protocol forgets you after every response.
- If a system is stateless, where does the state go?
- It moves out of the server's memory into a shared place: a database like PostgreSQL, a cache like Redis, or a signed token the client carries. The server stays interchangeable while the state lives somewhere every server can reach or that travels with the request.
- Why are stateless systems easier to scale?
- Because any server can handle any request, a load balancer can spread traffic freely across as many identical machines as you want. You can add or remove servers at will, and no user loses their session, which is exactly what horizontal scaling and auto-scaling need.
- Are JWTs the same thing as being stateless?
- JWTs are a common way to achieve statelessness, not a synonym for it. A self-contained signed token lets the server verify identity without looking up server-side session data. You can also be stateless using a shared session store; the token is just one popular approach.
- When should I choose stateful instead?
- Pick stateful when the workload is inherently about ongoing live state, such as a multiplayer game loop, a real-time collaborative editor, or a long-lived WebSocket connection. Forcing those into a stateless model usually adds more cost and latency than it removes.
Learn Stateless hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Stateless as part of a larger topic.
Token-Based Authentication
Stateless authentication using signed tokens instead of server-side sessions
intermediate · security architecture
Stateless Stream Processing
Transform events independently, filtering, mapping, and routing without maintaining state
advanced · stream batch processing
Stateless vs Stateful Systems
Two fundamental architecture patterns that shape how systems handle data, scale, and recover from failure
foundation · core fundamentals
Session Management
How servers remember who you are between requests in a stateless protocol
foundation · core fundamentals
Sticky Sessions
Pinning users to the same server, when stateless just isn't possible
foundation · load balancing proxies
See also
Related glossary terms you might want to look up next.
Stateful
A system that remembers previous interactions. The server keeps track of client state between requests, making it harder to scale but sometimes necessary.
Session
A way to maintain state across multiple HTTP requests. The server stores data about a user and gives them a session ID (usually in a cookie).
Horizontal Scaling
Adding more machines to handle increased load (scaling out). Like opening more checkout lanes instead of making one cashier faster.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.