Stateless Services
A stateless service holds no in-memory state between requests. Any server instance can handle any request because all persistent state lives in an external store.
Stateless waiters: they don't remember your order -- it's written on the ticket. Any waiter can deliver your food because the ticket (JWT) carries all the info.
Statelessness is the prerequisite for horizontal scaling. It enables any-to-any load balancing, zero-downtime deployments (blue/green, canary), and effortless auto-scaling. State is externalized to a database, distributed cache (Redis), or object store (S3). Session tokens (JWTs) let clients carry their own state, validated by any server without a central session store.
True statelessness is harder than it looks. 'Warm' state like in-memory caches or compiled regex patterns are fine (they're reconstructible). Problematic state includes: local file writes (use S3), in-process websocket connections (requires sticky sessions or a pub/sub broker for fan-out), and in-memory rate limiting counters (must use Redis for distributed counting). For WebSocket servers, sticky sessions via L7 load balancers are a pragmatic middle ground, but the preferred approach routes all messages through a pub/sub layer (Redis pub/sub, Kafka) so any node can deliver to any connection.
For stateless design, I ensure the application tier stores no request-to-request state in process memory. Sessions use JWT tokens (stateless validation) or are stored in Redis (shared across instances). Any file uploads go to S3, not local disk. For WebSocket connections, I use sticky sessions at the load balancer plus a pub/sub broker so any backend node can publish to any connected client.
Thinking JWT eliminates all session management concerns. JWTs can't be revoked server-side without a token blacklist (which reintroduces state), so logout and permission revocation require careful design.