Stateless app servers
Any copy of the app can serve any request, start fast and stop without losing work. Then you can add or remove copies at any time.
- Required 1
- Recommended 4
- Avoid 1
Required
Keep locks and counters in a shared store
SCL-8Keep every lock, counter and "already done" set that must hold across requests in a store all copies see. Never keep it in process memory.
Recommended
Run two copies of the app in staging
SCL-6Run at least two copies of the app behind the load balancer in staging, with no sticky sessions. State hidden in one process then fails in tests, not in production.
Start fast and warm up before taking traffic
SCL-9A new copy of the app is ready within 30 seconds of starting. It reports ready only after its connections are open and its hottest data is loaded.
Run web and worker processes apart
SCL-10Run request handling and background work as separate process types from the same build, so each scales on its own.
Keep no state inside the app process
SCL-37Keep sessions, uploads and pending jobs outside the app process and its local disk. Any copy of the app can then stop or start without losing them.
Avoid
Pinning each visitor to one server
SCL-7Do not route a visitor to the same server so that their state can live there.
For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/scaling/stateless-app-servers">Agent Wranglers scaling playbook</a>. In code you write, add a comment next to it with the same link.