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 that remembers previous interactions. The server keeps track of client state between requests, making it harder to scale but sometimes necessary.
In short
A stateful system remembers information about previous interactions with a client, so each request can depend on what happened before. The server stores that information (session data, connection state, in-progress work) either in memory or on disk, which means a given client's requests usually have to keep landing on the server that holds their state.
In short
A stateful system remembers information about previous interactions with a client, so each request can depend on what happened before. The server stores that information (session data, connection state, in-progress work) either in memory or on disk, which means a given client's requests usually have to keep landing on the server that holds their state.
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 Stateful across a run of lessons, not one page. These 3 alone are about 77 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.
Managing stateful applications in Kubernetes, stable network identities, ordered deployment, and persistent storage per pod.
Maintaining state across events, aggregations, joins, and pattern detection in streaming data.
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
State is just data that a server holds about a client between requests. When a system is stateful, the server uses that stored data to interpret the next request. A shopping cart that survives across page loads, a logged-in session, a multiplayer game keeping your position, a WebSocket connection holding an open channel: all of these are state living on the server side.
The opposite is stateless, where every request carries everything the server needs to handle it, and the server forgets the client the moment it sends a response. HTTP itself is stateless by design. Stateful behavior is something you add on top, usually because the application genuinely needs to remember context.
The key distinction is dependence. In a stateless system, request number 50 looks identical whether it follows request 49 or runs in isolation. In a stateful system, request 50 only makes sense because the server still remembers requests 1 through 49.
The server allocates storage for each client and ties it to an identifier. For web sessions that identifier is usually a session ID stored in a cookie; the server keeps the matching session data in memory or in a store like Redis. For long-lived connections like TCP, WebSockets, or a database connection, the state is the connection itself: sequence numbers, buffers, authentication context, all held in the server process.
Because the state lives on one specific machine, requests from the same client normally have to return to that same machine. This is called session affinity or sticky sessions, and load balancers implement it by hashing the client IP or reading a session cookie so they always route a user back to the server that holds their data.
If that server crashes or restarts, the in-memory state is gone. The user gets logged out, the cart empties, the game disconnects. This is the core operational cost of statefulness: the data has a home, and losing the home loses the data unless you replicate or persist it elsewhere.
Stateful is the right choice when keeping context on the server is cheaper or simpler than sending it on every request. Real-time systems lean stateful: a chat server holding open WebSocket connections, a game server tracking thousands of players, a streaming pipeline that buffers partial events. Stateful databases are stateful by definition, since their whole job is to durably remember data.
The cost is scaling. Stateless servers are interchangeable, so you can add or remove instances freely and route any request anywhere. Stateful servers are not interchangeable; you have to keep clients pinned to their server, deal with uneven load when one server holds heavy users, and handle failover carefully so a crash does not wipe live state.
A common compromise is to externalize the state. Keep the application servers stateless and push session data into a shared store like Redis or a database. Now any server can handle any request by reading state from the shared layer, and you get stateless scaling while still remembering the client. The trade-off moves to network latency and the load on that shared store.
Picture a video call on Zoom. When you join, a media server accepts your connection and starts tracking your audio and video streams, your mute status, who is speaking, and how to route packets between participants. That is all live state held in the server process for the duration of the call.
Your client cannot just send the same join request to any random server and expect the call to continue, because only the server holding your call state knows what is going on. Your traffic stays pinned to that one media server. If it fails, the call drops and clients have to reconnect and rebuild state on a new server.
Contrast that with fetching a static image from a CDN. Any edge node can serve it because the request carries everything needed and the server remembers nothing afterward. That is stateless, and it is why static content scales almost infinitely while live calls require careful capacity planning per server.
Redis
Commonly used as an external session store so app servers stay stateless while still remembering each user's login and cart.
PostgreSQL
A stateful service by nature: it durably holds your data and maintains per-connection transaction state on the server.
Kubernetes StatefulSets
A dedicated controller for stateful workloads that gives each pod a stable identity and its own persistent storage.
Zoom
Media servers hold live call state per session, so participants stay pinned to the server tracking their streams.
A stateful server remembers data about a client between requests, so later requests depend on earlier ones. A stateless server forgets the client after each response, so every request must carry all the information it needs. Stateless scales more easily; stateful is needed when context must persist on the server.
HTTP is stateless. Each request is independent and the server does not remember previous requests on its own. Statefulness like login sessions is layered on top using cookies, session IDs, and a server-side store such as Redis.
Because each client's state lives on one specific server, requests must keep returning to that same server through sticky sessions. You cannot freely add, remove, or swap servers, load can become uneven, and a server crash loses any in-memory state unless it is replicated or persisted.
Yes, by externalizing the state. Move session and connection data out of the app server into a shared store like Redis or a database. The app servers become stateless and interchangeable, while the shared store remembers the client. You trade some latency and add load on that store.
Yes. A database's entire purpose is to durably remember data, and it also keeps per-connection and per-transaction state on the server. That is why databases run as carefully managed stateful services rather than disposable, swappable instances.
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.
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).
WebSocket
A protocol for full-duplex communication over a single TCP connection. Unlike HTTP, the server can push data to the client without being asked.
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 Stateful 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.
