Database Scaling Patterns
As applications grow, a single database server often becomes a bottleneck.
To handle more users and data, we use scaling patterns.
This article covers the two fundamental approaches (vertical vs horizontal) and the techniques of replication and sharding.
1. Vertical vs Horizontal Scaling
1.1 Vertical Scaling (Scale-Up)
- Add more power (CPU, RAM, SSD) to a single server.
- Example: Upgrading from 4-core/16GB RAM → 32-core/256GB RAM.
Pros
- Simple to implement.
- No application changes needed.
- Great short-term solution.
Cons
- Hardware has limits (can’t scale forever).
- Expensive at higher tiers.
- Still a single point of failure (SPOF).
👉 Used as a first step, but not sustainable long-term.
1.2 Horizontal Scaling (Scale-Out)
- Add more machines (nodes) to handle the load.
- Example: Instead of one large server, use 10 smaller servers.
Pros
- Effectively unlimited scaling.
- Fault tolerance improves (no single point of failure).
- Cost-efficient with commodity hardware.
Cons
- Much more complex (distributed queries, replication, consistency).
- Requires careful architecture.
👉 Used in modern distributed systems (e.g., Google Spanner, Cassandra).
2. Replication Strategies
Replication = copying data across nodes.
2.1 Primary-Secondary Replication
- Writes → Primary, Reads → Replicas.
- Example: MySQL with read replicas.
Benefits
- High availability.
- Read scalability.
- Disaster recovery.
Challenges
- Replication lag → stale reads.
- Failover complexity.
2.2 Multi-Primary Replication
- Writes allowed on multiple nodes.
- Example: PostgreSQL BDR, CouchDB.
Benefits
- Higher write availability.
- Better geo-distribution.
Challenges
- Conflict resolution (last-write-wins, vector clocks).
- Complex consistency guarantees.
2.3 Geo-Replication
- Replicate data across regions/data centers.
- Example: Spanner, Cosmos DB.
Benefits
- Low latency (closer to users).
- Disaster resilience.
Challenges
- Cross-region latency.
- Cost of synchronization.
3. Sharding Techniques
Sharding = splitting data into subsets across nodes.
3.1 Range-Based Sharding
- Partition data by value ranges (e.g., user IDs 1–1000, 1001–2000).
- Pros: Easy to query ranges.
- Cons: Hotspot risk (popular range gets overloaded).
3.2 Hash-Based Sharding
- Apply a hash function on key → assign to shard.
- Pros: Even distribution of load.
- Cons: Hard to do range queries.
3.3 Directory-Based Sharding
- Use a lookup service that maps keys → shards.
- Pros: Flexible, dynamic rebalancing.
- Cons: Directory is a single point of failure if not managed well.
4. Combining Scaling Patterns
Most large-scale systems combine replication + sharding:
- Sharded Cluster with Replication inside each Shard
- Each shard stores a portion of the data.
- Each shard is replicated for fault tolerance.
Example Systems:
- MongoDB Sharded Cluster.
- Cassandra (partitioning + replication).
- Google Spanner (global sharding + replication).
5. Choosing the Right Strategy
Ask these questions:
Is the workload read-heavy or write-heavy?
- Read-heavy → Replication.
- Write-heavy → Sharding.
Is the dataset too large for one machine?
- Yes → Sharding.
Is high availability a must?
- Yes → Replication.
Do you need low-latency geo-distribution?
- Yes → Geo-replication.
6. Interview Tips
- Start with vertical scaling, then move to horizontal scaling.
- Always mention replication lag and shard rebalancing challenges.
- Show awareness of combining strategies.
- Tie answers back to CAP/PACELC trade-offs.
👉 Example Answer:
“I’d first try vertical scaling. If the workload grows further, I’d move to horizontal scaling. For a read-heavy workload, replication makes sense. For write-heavy with large datasets, sharding is needed. In practice, I’d combine both — each shard is replicated for HA.”
7. Recap
- Vertical scaling: quick but limited.
- Horizontal scaling: distributed, complex, scalable.
- Replication: improves availability & read scaling.
- Sharding: improves write scaling & storage capacity.
- Real-world systems combine both.
Next Steps
👉 Continue with Specialized Databases to learn how different database types (Key-Value, Document, Graph, etc.) solve unique scaling challenges.