Upgrading Hardware
Vertical scaling means upgrading the hardware of existing servers.
How Vertical Scaling Works
Before (Small Instance):
┌──────────────────┐
│ t3.medium │
│ 2 vCPU │
│ 4 GB RAM │
│ 50 GB SSD │
│ Handles: 500 RPS│
└──────────────────┘
After (Large Instance):
┌──────────────────┐
│ t3.xlarge │
│ 4 vCPU │
│ 16 GB RAM │
│ 200 GB SSD │
│ Handles: 2000 RPS│
└──────────────────┘
Hardware Upgrade Options
| Component | Upgrade | Impact |
|---|---|---|
| CPU | More cores, higher frequency | More concurrent processing |
| RAM | More memory | Larger datasets in memory |
| Storage | SSD, larger capacity | Faster I/O, more storage |
| Network | 10Gbps, 25Gbps | Higher throughput |
Cloud Instance Scaling
AWS Instance Types:
General Purpose: t3, m5, m6i
Compute Optimized: c5, c6i
Memory Optimized: r5, r6i, x1e
Storage Optimized: i3, d2
GPU: p3, p4, g4
Example Scaling Path:
t3.medium (2 vCPU, 4GB) → t3.large (2 vCPU, 8GB)
→ t3.xlarge (4 vCPU, 16GB) → m5.2xlarge (8 vCPU, 32GB)
→ m5.4xlarge (16 vCPU, 64GB) → r5.4xlarge (16 vCPU, 128GB)
Vertical Scaling Benefits
1. Simplicity
- No code changes
- No architecture changes
- Single server to manage
2. Strong Consistency
- Single node = no distributed issues
- ACID transactions easy
3. Lower Cost (at small scale)
- One server cheaper than many
- No load balancer needed
4. Performance
- No network overhead
- Local memory access
Limits of Vertical Scaling
Vertical scaling has hard limits that eventually require horizontal scaling.
Hardware Limits
Maximum Instance Sizes (AWS, 2024):
CPU: Up to 448 vCPU (u-6tb1.metal)
RAM: Up to 24 TB (u-6tb1.metal)
Storage: Up to 256 TB (io2)
Network: Up to 100 Gbps
But:
- Extremely expensive
- Single point of failure
- Downtime for upgrades
Cost vs Performance
Instance Size Cost/Hour Performance
─────────────────────────────────────────
t3.medium $0.042 500 RPS
t3.large $0.084 1000 RPS
t3.xlarge $0.168 2000 RPS
m5.2xlarge $0.384 4000 RPS
m5.4xlarge $0.768 8000 RPS
r5.4xlarge $1.008 10000 RPS
Cost grows faster than performance!
Availability Limitations
Single Server:
- No failover (single point of failure)
- Downtime for upgrades
- Hardware failure = complete outage
Example:
Server: 99.9% availability
= 8.76 hours downtime/year
With redundancy:
2 servers: 99.99% availability
= 52.6 minutes downtime/year
When Vertical Scaling Hits Limits
Signs you've hit vertical scaling limits:
1. CPU consistently > 70%
2. Memory consistently > 80%
3. Disk I/O consistently high
4. Network bandwidth maxed
5. Cost becomes prohibitive
Solution: Start horizontal scaling
Vertical vs Horizontal Comparison
| Factor | Vertical | Horizontal |
|---|---|---|
| Complexity | Low | High |
| Maximum Scale | Hardware limited | Nearly unlimited |
| Fault Tolerance | Single point of failure | Multiple nodes |
| Cost at Scale | Expensive | Commodity hardware |
| Downtime | Required for upgrades | Zero-downtime |
| Consistency | Strong (single node) | Eventual (distributed) |
When to Use
Vertical scaling is appropriate in specific scenarios.
Best Use Cases
1. Databases (Initial)
- Single primary database
- Easier than sharding
- Strong consistency
2. Small to Medium Workloads
- < 10K RPS
- < 100K concurrent users
- Budget constrained
3. Legacy Applications
- Not designed for distribution
- Monolithic architecture
- Hard to refactor
4. Development/Testing
- Simple environments
- Cost-effective
5. When Simplicity is Priority
- Small team
- Quick to implement
- No distributed system expertise
Scaling Strategy by System Size
Small System (< 1K users):
- Vertical scaling
- Single database
- Simple architecture
Medium System (1K-100K users):
- Vertical + some horizontal
- Read replicas
- Caching layer
Large System (> 100K users):
- Primarily horizontal
- Microservices
- Sharding
Database Vertical Scaling
Database Scaling Path:
1. Vertical Scaling (first)
- Upgrade instance size
- Add RAM, CPU, storage
- Simple, no code changes
2. When Vertical Hits Limit
- Add read replicas
- Add caching (Redis)
- Connection pooling
3. When Still Not Enough
- Shard database
- Migrate to distributed DB
Hybrid Approach
Most systems use both:
Application Tier:
- Horizontal scaling (stateless)
- Load balancer
- Multiple instances
Database Tier:
- Vertical scaling (primary)
- Read replicas (horizontal)
- Caching layer
Example:
- 10 web servers (horizontal)
- 1 powerful database (vertical)
- 3 read replicas (horizontal)
- Redis cache (horizontal)
Practice Problems
Design a scalable Vertical Scaling system. Cover high-level architecture, data model, and API design.
Solution
// Complete system design:
// - Functional + Non-functional requirements
// - Capacity estimation
// - Data model (SQL/NoSQL choice)
// - API endpoints
// - Component architecture
// - Scaling strategy
// - Monitoring & reliabilityHow would you scale Vertical Scaling to handle 10x the current load? Identify bottlenecks and solutions.
Solution
// Scaling approach:
// 1. Load balancing
// 2. Database sharding/replication
// 3. Cache layer (Redis)
// 4. CDN for static assets
// 5. Async processing (queues)
// 6. Microservices decompositionAnalyze potential failure modes for Vertical Scaling and design mitigation strategies.
Solution
// Failure mitigation:
// 1. Redundancy (multi-AZ)
// 2. Circuit breakers
// 3. Retry with backoff
// 4. Dead letter queues
// 5. Health checks
// 6. Graceful degradationQuiz
1. What is vertical scaling?
2. What is the main limitation of vertical scaling?
3. When is vertical scaling most appropriate?
4. What is a hybrid scaling approach?
Flashcards
Question
What is vertical scaling?
Click to reveal answer
Answer
Upgrading hardware (CPU, RAM, storage) of existing servers. Simple, no code changes, but has hardware limits and creates single point of failure.
Question
What are the limits of vertical scaling?
Click to reveal answer
Answer
Hardware maximums, cost grows faster than performance, single point of failure, downtime for upgrades, eventually requires horizontal scaling.
Question
When should you use vertical scaling?
Click to reveal answer
Answer
Small/medium workloads, databases (before sharding), legacy applications, when simplicity is priority, development/testing environments.
Question
What is a hybrid scaling approach?
Click to reveal answer
Answer
Horizontal scaling for stateless application servers + vertical scaling for databases. Most common real-world approach combining benefits of both.
Question
What is Vertical Scaling?
Click to reveal answer
Answer
Vertical Scaling is a key concept in system design.
Revision Notes
Key Takeaways
- 1.Vertical scaling is simpler but has hardware limits
- 2.Cost grows faster than performance at high scale
- 3.Best for databases initially, before sharding needed
- 4.Most systems use hybrid: horizontal for apps, vertical for databases
- 5.Switch to horizontal when vertical limits are reached
Interview Tips
- •Start with vertical scaling for databases before suggesting sharding
- •Discuss when you'd switch from vertical to horizontal
- •Consider hybrid approaches for different system tiers
- •Mention cost implications of large instances
Cheat Sheet
Vertical Scaling - Cheat Sheet
What it is:
Upgrading hardware of existing servers.
Benefits:
- Simple (no code changes)
- Strong consistency
- Lower cost at small scale
- No network overhead
Limits:
- Hardware maximums
- Cost grows faster than performance
- Single point of failure
- Downtime for upgrades
When to Use:
- Small/medium workloads
- Databases (initial)
- Legacy applications
- Simplicity priority
Hybrid Approach:
- App tier: Horizontal
- Database: Vertical + read replicas
- Cache: Horizontal (Redis)