We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Core Fundamentals
A system where each request contains all the information needed to process it. The server doesn't remember previous requests. Easier to scale horizontally.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Stateless across a run of lessons, not one page. These 4 alone are about 92 minutes of step-by-step reading, every one with a quiz.
Two fundamental architecture patterns that shape how systems handle data, scale, and recover from failure.
Stateless authentication using signed tokens instead of server-side sessions.
Transform events independently, filtering, mapping, and routing without maintaining state.
How servers remember who you are between requests in a stateless protocol.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Stateless vs Stateful Systemspay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Token-Based Authentication
Stateless authentication using signed tokens instead of server-side sessions
Stateless Stream Processing
Transform events independently, filtering, mapping, and routing without maintaining state
Session Management
How servers remember who you are between requests in a stateless protocol
Sticky Sessions
Pinning users to the same server, when stateless just isn't possible
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.
This page explains the idea. The "Stateless vs Stateful Systems" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Stateless vs Stateful Systems lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Stateless in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
