Topic 9.2
Horizontal Scaling
In one line
More machines behind a load balancer — the scalable path that demands statelessness.
Think of it like this
Opening more stalls at a food festival instead of building one giant kitchen. If one stall runs out of gas, the other nine keep serving customers. But it only works if any stall can serve any customer's order.
Key ideas
- 01
Add nodes → add capacity; no single point of failure (with N nodes, kill one and the rest carry on).
- 02
Requires stateless services: any request → any node → same result (state moved to DB/Redis).
- 03
The session problem: user sessions must leave the node (Redis session store) or requests become sticky-required.
- 04
Database is the usual wall: app servers scale easily; the DB is where vertical/scaling-replication/shards begin.
- 05
Autoscaling plus=per-cost: add nodes on CPU/queue signal, remove on idle.
- 06
Interview line: 'I'll keep services stateless so the fleet is a pool of identical interchangeable nodes.'
Java / Spring map
- →
Spring Boot: stateless REST + Redis-backed sessions + a shared DB; health endpoint for the LB.
Code & diagrams
Explain without notes
What breaks if the app keeps a user's cart in a HashMap on one instance and the LB routes a retry to another?
Practice
Audit a Spring Boot app for hidden per-instance state (in-memory caches, sessions, locks).
Trade-offs
- ↔
Statelessness costs a dependency hop (every read to Redis/DB) in exchange for infinite-ish scale.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I treat statelessness as the prerequisite, not the option, of horizontal scaling.