Horizontal scaling

Horizontal scaling adds more instances of the same service instead of bigger machines. It works best when app tiers are **stateless**: session data in Redis, uploads in object storage, sticky sessions only when unavoidable.

					Traffic → LB → [App₁, App₂, App₃] → Shared DB / Cache / Queue
				

| Requirement | Why | |-------------|-----| | Stateless handlers | Any instance can serve any request | | Shared durable state | DB, cache, object storage—not local disk | | Health checks | LB removes bad instances | | Autoscaling signals | CPU, RPS, queue depth, custom SLI |

Plan for **rolling deploys** and connection math: more instances mean more DB pool connections unless you use a pooler.

On interviews: stateless vs sticky sessions; when vertical scale is simpler; autoscaling lag during spikes; data locality trade-offs.

Common pitfalls: in-memory sessions on multiple pods; local file uploads; scaling before fixing synchronous DB bottleneck.

The trade-off is elastic capacity versus distributed-system complexity and cost of N small machines.

Checklist:

• Externalize session and upload state.
• Autoscale on user-visible signals where possible.
• Test deploy with extra instances joining mid-traffic.
• Account for connection limits per instance.