Stateless Architecture: The Foundation of Horizontal Scaling

Core Principle
A stateless service stores no client data between requests. Every request contains all information needed to process it. Any server can handle any request, enabling free load balancer routing.
WHY STATELESS ENABLES SCALING
Stateful servers remember things between requests: carts, sessions, cached data. If Server A remembers your cart, you must always return to Server A (sticky sessions). Server A fails? Cart vanishes. Server A overloaded? Cannot shift traffic elsewhere.
Stateless servers have none of these problems. Add a server, immediately route traffic to it. Server fails? Route to another. No coordination, each request self-contained.
WHERE DOES STATE GO?
State moves to dedicated stores:
Session state: Redis or Memcached. Sub-millisecond reads, automatic expiration. Any server fetches session from shared store.
Persistent data: Databases. Cart items, profiles. Replicated for durability.
Client state: JWTs or cookies. User carries their auth token. Server verifies signature without database lookup.
Trade-off: Externalizing state adds network hops. Fetching session from Redis adds 0.5 to 2ms per request. For most applications, this is negligible compared to the scaling flexibility gained.
STATELESS IN PRACTICE
A stateless API receives request with JWT, validates signature locally, fetches data from database or cache, computes response, returns it. Remembers nothing. Process, forget, repeat.
Key Test: Can you kill any server at any time without losing user data or breaking sessions? If yes, you are stateless. If no, find the hidden state and externalize it.

💡 Key Takeaways

✓Stateless services store no client data between requests, allowing any server to handle any request and enabling linear horizontal scaling without coordination overhead

✓Externalize sessions to Redis (100K to 300K ops per second, sub millisecond latency), file uploads to S3 (unlimited throughput, 99.99% availability), and job state to message queues

✓Sticky sessions indicate accidental statefulness; they prevent true horizontal scaling and create single points of failure when the pinned server fails

✓JWTs enable stateless authentication by encoding user identity in signed tokens that any server can verify without querying a central session store

✓The latency cost of external state (0.5 to 2ms per Redis lookup) is negligible compared to the scaling flexibility gained by making services stateless

📌 Interview Tips

1When designing any web service, explicitly state "API servers will be stateless" early. This signals you understand horizontal scaling fundamentals.

2If asked where session data goes, mention Redis with TTL for ephemeral state, and explain JWTs for auth tokens that servers can validate without database lookups.

3A common follow-up is "what if Redis fails?" Have an answer: session recreation from database, graceful degradation, or multi-region Redis replication.

← Back to Scalability Fundamentals Overview