Theory
Stateless vs Stateful Systems
📋 Overview
In system architecture, the distinction between stateless and stateful design dictates how a service manages information across multiple requests. This choice fundamentally impacts horizontal scalability, fault tolerance, and the complexity of the underlying infrastructure.
🏗️ Core Principles & Characteristics
- Statelessness:
- Each request is treated as an independent transaction.
- The server does not store any context about the client between requests.
- All necessary data (authentication tokens, state) is passed in every request.
- Statefulness:
- The server maintains "session state" for each client.
- Subsequent requests depend on the results of previous ones.
- The server often stores this state in memory or local disk, creating an affinity between a client and a specific server instance.
⚖️ Trade-offs: Pros & Cons
Stateless
- Pros: Extreme horizontal scalability (any server can handle any request), simplified failover, easier caching.
- Cons: Increased payload size (sending tokens/state every time), potentially more database lookups to re-verify state.
Stateful
- Pros: Lower payload size (only session ID needed), faster subsequent requests as state is "warm" in memory.
- Cons: Scaling is difficult (requires sticky sessions or session replication), server failure leads to session loss, complex "zombie" session cleanup.
🌍 Real-World Implementation
- RESTful APIs (Stateless): Using JWT (JSON Web Tokens) to carry user identity and permissions in every header.
- Game Servers (Stateful): Maintaining real-time player positions, health, and inventory in memory for low-latency updates.
- E-commerce Carts (Mixed): Historically stateful (stored in server session), but modern designs use stateless approaches (stored in client-side cookies or a centralized Redis cache).
- TCP Protocol (Stateful): The protocol itself maintains sequence numbers and window sizes to ensure reliable delivery.
💡 Interview "Gotchas" & Tips
- "Is a Database Stateless?": No. Databases are the ultimate stateful components. Applications are often "stateless" only because they offload state to a stateful database.
- Sticky Sessions: Mention that stateful apps often require "Session Affinity" at the load balancer, which can lead to uneven load distribution.
- Scaling the State: If an app must be stateful, explain how to scale it using a distributed cache (like Redis) rather than local in-memory storage.
📐 Suggested Architecture Primitives
- Centralized Cache: Redis or Memcached to store state outside the application process.
- Tokens: JWT for stateless authentication.
- Load Balancers: Configured for Round Robin (Stateless) or Sticky Sessions (Stateful).
- Distributed Databases: To serve as the "Source of Truth" for state in a stateless architecture.
Canvas