How it works
Draw the boundary around the application service, not the whole system. A stateless API can read and update a stateful database; it simply does not keep the only authoritative copy of session or business data inside an application instance.
Each request carries enough context to identify the caller and operation. For example, a session cookie contains an opaque session ID, and any API instance can use that ID to load the session from a shared store. A signed token is another option, with different expiration and revocation trade-offs.
Put information needed across requests in an appropriate shared system. Store orders in a database, upload progress in shared metadata storage, and durable job progress in a queue or workflow store. If instance A disappears, instance B can continue from that shared state.
A load balancer distributes requests among healthy instances without requiring session affinity. Adding an instance does not require transferring user sessions to it, although it may still need time to initialize connection pools and warm caches.
Stateless does not mean empty memory. Instances can keep connection pools, request-local variables, and disposable caches, provided losing them does not lose authoritative data or break correctness. Long-lived connections still belong to particular instances and need explicit reconnect and routing behavior.
A worked example
Scaling an authenticated API without sticky sessions
Suppose an API receives 6,000 requests per second. Load tests show one instance can sustain 1,000 requests per second at the target latency, so you provision eight instances for headroom. Each request includes a session ID; any instance can load the session from a shared store and access business records in the database. When one instance fails, seven remain, and no session transfer is needed. In-flight requests may still fail. Clients retry eligible operations, while shared idempotency records protect writes from duplication. Before adding more replicas, check database capacity and connection limits: stateless API capacity does not imply unlimited backend capacity.
Trade-offs to say out loud
- Simpler horizontal scaling
- Instances are easier to add and remove, but shared databases, queues, and session stores can still limit total capacity.
- More shared-store dependencies
- Externalizing state can add network calls and makes the latency and availability of shared stores part of the request path.
- Easier instance replacement, not automatic recovery
- A replacement can handle subsequent requests, but interrupted work still needs retries, durable progress, or explicit recovery.
- Concurrency moves to shared storage
- Requests on different instances can update the same record, so transactions, conditional writes, or other concurrency controls remain necessary.
- Authentication has separate state choices
- Shared sessions support centralized revocation, while self-contained tokens reduce session lookups but complicate immediate revocation and permission freshness.
- Local optimizations require care
- Per-instance caches and counters can improve performance, but cannot silently become the authority for global limits or durable business decisions.
When to reach for it
- An HTTP API must scale horizontally behind a load balancer without pinning users to individual servers.
- The design needs rolling deployments, autoscaling, or instance replacement without losing sessions or business progress.
- Workers should resume queued jobs after another worker fails, using durable job state rather than local memory.
- A system mixes ordinary API requests with stateful components such as WebSocket gateways, document owners, or storage servers, and you need to define the boundary.
How to bring it up in the interview
- Name exactly what is stateless: 'The API tier is stateless; sessions live in a shared store and orders live in the database.' Interviewers will probe what happens when either store fails.
- Walk through two consecutive requests reaching different instances, then kill the first instance mid-request. Explain what survives, what gets retried, and how duplicate effects are prevented.
- Separate application scaling from storage scaling. Adding API replicas helps only while downstream capacity, connection limits, and hot records allow it.
- Defend exceptions rather than forcing everything to be stateless. For WebSockets or partition-owned processing, explain connection ownership, routing, durable state, and recovery.
- Distinguish stateless servers from self-contained authentication tokens. A stateless application tier can use server-side sessions, and token validation does not eliminate every need for shared security state.
Common mistakes
- Saying a stateless system has no database or never changes data.
- Keeping sessions, shopping carts, or multi-step workflow progress only in instance memory, then assuming any replica can serve the next request.
- Treating sticky sessions as failover protection; affinity does not recover local state when an instance dies.
- Assuming stateless requests are automatically idempotent or that retries cannot duplicate writes.
- Calling WebSocket gateways fully interchangeable while ignoring their instance-local connections and reconnect behavior.
Where it comes up
Interview questions where stateless services is part of a strong answer, and why.
- Design a login and authentication systemSession validation and revocation require distinguishing stateless authentication servers from the shared or token-carried state they use.
- Design a chat app like WhatsAppA good design separates stateless APIs from connection-owning chat servers and explains routing and recovery when a connection server fails.
- Design a distributed job schedulerReplaceable dispatchers and workers must keep execution progress, leases, and retry state outside process memory to survive failures.
Questions people ask
What is the difference between stateless and stateful services?
A stateless service does not require a particular instance to remember earlier requests to handle the next one. A stateful service maintains instance-specific state that affects subsequent processing, such as an active connection, an owned data partition, or an in-memory session.
Can a stateless service use a database or server-side sessions?
Yes. Statelessness describes the application instance's responsibility, not the absence of stored data. If every instance can retrieve the same session and business state from shared storage, the application tier can remain stateless.
Are stateless services always better than stateful services?
No. Stateless application tiers simplify replacement and request distribution, but external state access adds latency and dependencies. Stateful components are often appropriate for storage, long-lived connections, and ordered processing, provided ownership and recovery are designed explicitly.