Vertical vs Horizontal Scaling

Vertical Scaling (Scale Up)

Make the single machine bigger and more powerful. Same machine, just more resources (RAM, CPU, storage).

Horizontal Scaling (Scale Out)

Add more machines to share the load. More machines, same size per machine.

Head to Head

	Vertical	Horizontal
Cost curve	Exponentially expensive	Linearly expensive
Ceiling	Hard limit (biggest server)	No limit (add infinitely)
Downtime	Required to upgrade	Zero downtime
Complexity	Simple	Complex (distributed)
Failure risk	Single point of failure	Fault tolerant
Data consistency	Easy (one machine)	Hard (distributed)
Best for	Databases, simple systems	Web servers, microservices

The Ceiling Problem

Vertical scaling has a hard ceiling — no single server can handle Google's exabytes of data or Twitter's 500M tweets/day. Must scale horizontally.

Stateless vs Stateful

• Stateless service (easy to scale horizontally): each request has everything it needs, any server handles any request. API servers, web servers = stateless.
• Stateful service (hard to scale horizontally): server remembers things between requests. Databases = stateful. That's why DB horizontal scaling needs sharding, replication, consensus.

Real World Scaling Journey

Stage 1: Single server (Web + App + DB together)
Stage 2: Separate DB (vertical scaling both)
Stage 3: Add read replicas (offload reads horizontally)
Stage 4: Horizontal web tier (load balancer + multiple app servers)
Stage 5: Add caching (Redis layer)
Stage 6: Shard the database (horizontal DB)

Database Scaling Rule

Vertically scale DB as long as possible → add read replicas for reads → shard only when you must. Don't over-engineer early.