Horizontal scaling with a stateless tier
Horizontal scaling with a stateless tier
Gold
Run many identical, stateless app servers behind a load balancer. Capacity grows by adding servers, and losing one is survivable. State moves to shared stores.
- Use when
- Traffic beyond one server · Surviving a single server failure · Load that varies (pairs with autoscaling)
- Avoid when
- Stateful parts such as databases — they need replication or sharding instead
- Trade-offs
- More moving parts and more complex deploys · Shared dependencies become the next bottleneck
- Requires
- Load balancer, Split app and database tiers
3 objectives · 7 misconceptions
- explain Explain why session state must leave the app servers before scaling out.
- predict Predict how many servers a target load needs, given per-server capacity and headroom.
- diagnose Spot when adding app servers stops helping because a shared dependency is saturated.
- Not true: Doubling servers always doubles throughput.
- Not true: Sticky sessions are as good as stateless servers.
- Not true: Each server can keep its own users' session data when you scale out.
- Not true: If the servers carry today's traffic, they will survive losing one.
- Not true: When one server dies, the others keep only their old share of the traffic.
- Not true: A stateless app stores no data anywhere.
- Not true: Slow pages are fixed at the web tier, whatever the shared parts are doing.
Learn
Horizontal scaling with a stateless tierFree with an account~10 minPractice
Launch dayFree with an accountmediumCheck
Station test-out80% to passStories here
Neighborhood
→Horizontal scaling with a stateless tier→
contrast withServer capacity & scaling up