What does it mean for a service to be stateless, and why does it matter?
Quick Answer
A stateless service keeps no client-specific data in its own memory between requests — everything needed is in the request itself or fetched from a shared store (database, Redis). That means any instance can handle any request, so you can add/remove/restart instances freely behind a load balancer.
Stateless means the service instance doesn't remember anything about a client from one request to the next — the request carries its own context, or the service looks it up in a shared database or cache. The reason it matters is horizontal scaling: if every instance is interchangeable, the load balancer can send request one to instance A and request two to instance B, you can autoscale, and a restart loses nothing. The moment you keep session state or a user-specific cache in process memory, you need sticky sessions and you lose data on every deploy. So you push that state out to Redis or the database.
- In-memory session or caches tie a user to one instance, forcing “sticky sessions” and breaking on restart/scale-in.
- Externalize state: distributed cache for sessions, database for data, object storage for files.
- Statelessness is a core REST constraint and a 12-factor principle.
- Genuinely stateful systems (real-time collaboration, game servers) exist, but they need deliberate design — partitioning, affinity, state replication.