Stateful
A system that remembers previous interactions. The server keeps track of client state between requests, making it harder to scale but sometimes necessary.
What is Stateful?
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.
What stateful actually means
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete example
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between stateful and stateless?
- 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.
- Is HTTP stateful or stateless?
- 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.
- Why are stateful systems harder to scale?
- 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.
- Can you make a stateful application scale like a stateless one?
- 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.
- Are databases stateful?
- 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.
Learn Stateful 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 Stateful as part of a larger topic.
StatefulSets
Managing stateful applications in Kubernetes, stable network identities, ordered deployment, and persistent storage per pod
intermediate · kubernetes containers
Stateful Stream Processing
Maintaining state across events, aggregations, joins, and pattern detection in streaming data
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
See also
Related glossary terms you might want to look up next.
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.