What's the difference between a stateless server and a stateful server in a client-server system, and why does it matter for scaling and failover?

## Where the context lives Statelessness vs statefulness describes where a client-server system stores the context needed to make sense of a sequence of related requests. - **In a stateless design**, the server processes each incoming request in complete isolation: it has no memory of anything the same client sent a moment ago, and it needs none, because the request itself contains everything required — an auth token, a resource identifier, a full set of parameters, maybe even a cursor pointing to where a paginated query left off. - **In a stateful design**, the server retains some per-client context between requests — commonly called a "session" — stored in the server's memory or in a data store the server owns, and subsequent requests are interpreted in light of that stored context. ## What each one looks like in practice Mechanically, a stateless HTTP API demonstrates this well: each call to something like `GET /orders/42` must include an `Authorization: Bearer <token>` header, and the server validates that token fresh on every single call — it doesn't remember validating it a second ago. A stateful alternative (older-style web apps, or a raw TCP protocol like FTP's control connection) has the server - allocate an in-memory session object the moment a client connects or logs in, - tag subsequent packets on that same connection with an implicit session ID, and - let the server's in-memory object accumulate state across many exchanges without the client re-sending it each time. ## Why statelessness is chosen The reason statelessness exists as a deliberate architectural choice — and it is a choice, not an inherent property of "client-server" as a style — is **scalability and resilience**. If no server instance holds unique, irreplaceable per-client state, then any request can be routed to any server instance behind a load balancer: you can add or remove server instances freely, and if one instance crashes mid-session, nothing is lost because nothing was held there in the first place. This is precisely why REST names statelessness as a required constraint: it's what lets HTTP-based systems scale horizontally to internet scale with commodity load balancing rather than sticky routing. ## What statelessness costs The trade-off is that statelessness pushes cost elsewhere. Every request now has to carry more data (tokens, full context) — bandwidth and per-request overhead go up, and in protocols with expensive per-request authentication, CPU cost goes up too. Multi-step interactions that are naturally sequential (a wizard-style checkout, an FTP-style file transfer) become awkward to model statelessly. You either 1. encode the whole interaction's progress into a token/resource the client passes back each time, or 2. introduce an external stateful store (e.g., a Redis-backed session, or a persisted "draft order" resource) that the stateless application servers read and write — which reintroduces state, just relocated out of the application server's memory into a dedicated store designed for that job. ## What statefulness buys, and what it charges Statefulness's upside is **efficiency and simplicity** for exactly those sequential interactions: the server can hold a partially-built object in memory across a conversation without the client re-transmitting everything, and per-request payloads shrink. Its cost is operational: you now need **session affinity** (sticky sessions), which complicates scaling and creates a real failure mode — if the server instance holding that session dies, the session and any unsaved progress in it is gone, unless the state was also replicated. ## How each one fails in production | Design | The shape of the failure | |---|---| | **Stateless** | In production, the stateless failure mode usually looks like tokens: expired or malformed tokens causing spurious 401s, or clock skew between servers causing token-expiry checks to disagree. | | **Stateful** | The stateful failure mode looks like "my session disappeared" after a deploy rolled the server instance, or uneven load because sticky sessions pin heavy users to specific nodes, creating hot spots a stateless load balancer would have smoothed out. | ## Where you have already seen it - **A concrete real-world instance:** REST APIs mandate statelessness as an explicit constraint, which is why nearly every modern public API (Stripe, GitHub, Twitter/X) requires the client to pass an API key or bearer token on every call rather than relying on the server remembering a prior login. - **Contrast that** with classic PHP session-based web apps using `PHPSESSID` cookies mapped to server-side session files — a stateful design that historically required sticky load-balancer configuration to work correctly at scale.