Stage 4 · Provision
Scalability & Capacity
Horizontal vs Vertical Scaling
CPU, memory, disk IOPS, and network ceilings that determine scale-up or scale-out choices.
Scaling Dimensions
Scaling happens along specific resource dimensions: CPU, memory, disk IOPS, and network bandwidth. Each dimension has a ceiling. Understanding which dimension you are hitting first determines whether vertical or horizontal scaling is more effective.
| Resource | Vertical Limit | Horizontal Approach |
|---|---|---|
| CPU | 128 vCPUs (cloud max) | Add more instances |
| Memory | 4TB (cloud max) | Distribute across instances |
| Disk IOPS | 256K IOPS (NVMe) | Shard across instances |
| Network | 100 Gbps | Load balance across instances |
Vertical Scaling Tradeoffs
- Simpler — No distributed systems complexity.
- Stronger consistency — Single node, no replication lag.
- Lower cost at small scale — One large instance is cheaper than many small ones.
- Hardware ceiling — Eventually you hit the largest available instance.
- Single point of failure — One node fails, everything fails.
- Downtime for resize — Most cloud providers require restart for instance resize.
Horizontal Scaling Tradeoffs
- Distributed systems complexity — Consensus, replication, partitioning.
- Eventual consistency — Replicas may serve stale data.
- Higher operational overhead — More instances to manage, monitor, deploy.
- Linear cost — Cost scales linearly with capacity.
- Theoretically unlimited — No hardware ceiling.
- Zero-downtime scaling — Add instances without downtime.
Ceiling Analysis
Current: db.r6g.xlarge (4 vCPUs, 32GB RAM)
CPU utilization: 70% at peak
Memory utilization: 60%
Disk IOPS: 50K / 100K available
Connections: 200 / 5000 max
Ceiling analysis:
CPU: 70% → Can vertical scale to r6g.2xlarge (8 vCPU)
Memory: 60% → Can vertical scale to r6g.4xlarge (128GB)
IOPS: 50% → No IOPS bottleneck
Connections: 4% → No connection bottleneck
Recommendation: Vertical scale to r6g.2xlarge
Doubles CPU headroom
No sharding complexity
Estimated to last 12-18 monthsIdentify the bottleneck resource. If it is CPU, vertical scaling is often the simplest solution. If it is write throughput across multiple resources, horizontal scaling may be needed.
Choosing a Strategy
Is the bottleneck a single resource (CPU, RAM)?
├── Yes → Vertical scale first
│ Still bottlenecked?
│ ├── Yes → Horizontal scale that resource
│ └── No → Done
└── No → Horizontal scale
Need global distribution?
├── Yes → Multi-region horizontal scale
└── No → Single-region horizontal scaleAlways exhaust vertical scaling before horizontal. Vertical is simpler, cheaper at small scale, and avoids distributed systems complexity.
Real-World Examples
| Service | Strategy | Why |
|---|---|---|
| Small SaaS (1K users) | Vertical | Simple, cheap, one instance is enough |
| Medium SaaS (100K users) | Vertical + read replicas | Scale reads horizontally, writes vertically |
| Large SaaS (10M users) | Horizontal sharding | Vertical limits reached, need distribution |
| Global platform (100M+ users) | Horizontal + multi-region | Global distribution required |
Many teams prematurely adopt sharding and microservices. A single PostgreSQL instance on a 64-vCPU machine with 256GB RAM handles most workloads. Start simple, scale up, then scale out when you hit the ceiling.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.