Stateless Service Design

Stateless services scale horizontally by adding instances. Stateful ones require coordination. Most "why won't this scale" problems start with accidental state.

How It Works

A stateless service holds no request-specific data between requests — every request carries all the context it needs, and any instance can handle any request. This is what makes horizontal scaling trivial: add another instance, route traffic to it. Stateful services (in-memory session stores, local file caches, WebSocket connection registries) require coordination — sticky routing, replication, failover — all of which add operational complexity. The architectural discipline: keep application-tier services stateless; push state explicitly to data stores (databases, caches, object stores) designed for coordination. In interviews, any box in your design that implies state should connect to a data store, not hold state locally.

Real-World Example

Netflix's microservice architecture enforces stateless services strictly — every instance is interchangeable, state lives in DynamoDB or Cassandra. When they auto-scale, new instances take over traffic immediately without session-affinity routing. The rare stateful service (like the streaming session handler) uses explicit state externalization — session state lives in Redis, not local memory — so the service looks stateless to the load balancer. This is why Netflix can replace any instance in seconds without user-visible disruption, and why auto-scaling is nearly free at their scale.