A city scales out replicas of a ticket-intake API behind a load balancer. Which 12-factor process design supports stopping and replacing any instance safely?

Processes should remain stateless and disposable, with session or job state kept in a shared backing store so any replica can serve the next request. That design lets the platform replace civic instances during rolling updates without stranding citizen sessions or in-flight work on a dying node, and it matches how orchestrators treat containers as replaceable units rather than unique hosts. Keeping active sessions only on each instance’s local disk mandates sticky affinity forever and turns a single node failure or reschedule into mass logout or lost municipal work. Storing in-flight job state solely in /tmp on the container filesystem fails the same way: the ephemeral layer disappears when the container is replaced, so another replica cannot resume the job. Pinning every citizen session to one replica IP written into memory at startup hard-codes topology into the process and breaks as soon as that IP or pod disappears. Exam caveat: “stateless processes” does not mean “no state anywhere”—it means durable state lives outside the process so horizontal scale, restart, and blue-green cutovers remain safe. Operational check: start a session or long-running job against one replica, deliberately terminate that pod or container, and confirm another replica resumes correctly from the shared store without client-visible loss beyond a clean reconnect.