Database Scaling

As your application grows, your database becomes a bottleneck. Here are strategies to scale it effectively.

Vertical Scaling (Scale Up)

Increase the resources of a single server:

• More CPU, RAM, SSD
• Simple but has limits
• Single point of failure

Horizontal Scaling (Scale Out)

Distribute data across multiple servers.

Read Replicas

Writes → Primary DB
Reads  → Replica 1, Replica 2, Replica 3

• Reduces read load on primary
• Eventual consistency trade-off
• Great for read-heavy workloads

Sharding

Partition data across multiple databases:

User ID 1-1000    → Shard 1
User ID 1001-2000 → Shard 2
User ID 2001-3000 → Shard 3

Sharding Strategies

1. Range-based: Partition by ID ranges
2. Hash-based: Partition by hash of key
3. Geographic: Partition by user location

Caching

Add a caching layer to reduce database load:

Client → Cache (Redis) → Database
         ↑ Cache Hit      ↑ Cache Miss

Cache Strategies

• Cache-Aside: Application manages cache
• Write-Through: Cache updated with database
• Write-Behind: Cache updated first, DB async

CAP Theorem

You can only guarantee two of three:

• Consistency: All nodes see the same data
• Availability: Every request receives a response
• Partition Tolerance: System works despite network partitions

Real-world: Most distributed databases choose AP or CP. True CA systems don’t exist in distributed environments.