Stateless services & horizontal scaling

To scale horizontally — add more servers behind a load balancer — every instance must handle every request identically. The moment you keep state IN MEMORY (sessions, caches, uploaded files), you break this: user's request A lands on server 1 with their state, request B lands on server 2 with nothing.

The three classic fixes: (1) external session store (Redis, DB, Memcached) — sessions live outside any single instance. (2) stateless tokens (JWT signed by the server) — no server-side session needed; the client carries the state in every request. (3) sticky sessions (load balancer pins a user to one server) — fragile; single server failure kills every user on it.

The same rule applies to anything in-process: caches (per-instance caches diverge), background jobs (in-request work dies when the process restarts), file uploads (saved to /tmp exist only on that one instance). Externalize all of them.

The mental model: design as if every request hits a brand-new, freshly-booted instance. If ANY part of your code wouldn't work in that world, you have hidden state that needs moving out. This is the 12-factor principle of statelessness.

The twelve-factor 'Processes' principle states this explicitly: 'Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.' Everything about horizontal scaling flows from this.