Modern systems need to scale, stay available, and handle failures gracefully.
Two core techniques help achieve this:
- Replication → Improves availability and read scalability
- Sharding → Enables horizontal scaling by distributing data
In real-world systems, both are often used together.
🔁 Replication
What is Database Replication?
Replication means maintaining multiple copies (replicas) of the same database across different servers.
Why Use Replication?
- High availability – If one replica goes down, others can still serve traffic
- Read scalability – Reads can be spread across replicas
- Fault tolerance – Reduces risk of complete data loss
Replication Models
1. Leader–Follower (Primary–Replica)
Structure
- One leader (primary) handles all writes
- One or more followers (replicas) copy data from the leader
Operations
- Writes → Leader
- Leader propagates changes to followers
- Reads → Leader + Followers
Pros
- Simple write model
- Works well for read-heavy workloads
Cons
- Write bottleneck at the leader
- Replication lag may cause stale reads
2. Leader–Leader (Multi-Primary)
Structure
- Multiple nodes act as leaders
- All nodes can handle reads and writes
Operations
- Writes can go to any leader
- Data must be synchronized across leaders
- Conflicts may occur
Pros
- Higher write availability
- Better fault tolerance
Cons
- Complex conflict resolution
- Increased latency and coordination overhead
Replication Modes
Asynchronous Replication
- Changes propagate to replicas in the background
Pros
- Low write latency
- Faster responses
Cons
- Temporary inconsistencies
- Possible stale reads
Synchronous Replication
- Writes are committed to leader and replicas simultaneously
Pros
- Strong consistency guarantees
Cons
- Higher write latency
- Slower overall performance
Key Replication Considerations
Conflict Resolution (Multi-Leader Systems)
Common strategies:
- Last-Write-Wins (LWW)
- Timestamp-based resolution
- Application-specific rules
📌 Example:
The update with the latest timestamp overwrites older conflicting changes.
Consistency vs Performance Trade-off
| Approach | Consistency | Performance |
|---|---|---|
| Synchronous | Strong | Slower writes |
| Asynchronous | Eventual | Faster writes |
🧩 Sharding
What is Database Sharding?
Sharding splits large datasets across multiple servers (shards), with each shard holding a subset of the data.
Benefits of Sharding
- Horizontal scaling – Handle more data by adding servers
- Improved performance – Smaller datasets per shard
- Reduced hotspots – Load is distributed
Shard Keys & Strategies
A shard key determines how data is distributed.
Common Sharding Strategies
🔹 Range-Based Sharding
IDs 1–1000 → Shard 1
IDs 1001–2000 → Shard 2
✅ Good for range queries
❌ Risk of uneven load
🔹 Hashed Sharding
- Hash function maps keys to shards
✅ Even data distribution
❌ Range queries become harder
🔹 Regional Sharding
- Data grouped by geography (US, EU, APAC)
✅ Lower latency
❌ Cross-region queries can be expensive
Query Implications
- Range queries may hit multiple shards
- Hashed sharding improves balance but complicates analytics
Sharding vs Replication
| Aspect | Replication | Sharding |
|---|---|---|
| Purpose | Availability & reads | Horizontal scaling |
| Data | Copied | Split |
| Writes | Same data | Partitioned data |
Real-World Approach
Most large systems combine both:
- Each shard is replicated
- Replication improves availability
- Sharding enables scale
Sharding in Practice
SQL Databases
- Often lack native sharding
- Require custom shard routing & rebalancing
- More operational complexity
NoSQL Databases
- MongoDB, Cassandra, etc. support sharding out-of-the-box
- Easier horizontal scaling
🧠 Key Takeaways
- Replication → High availability + read scaling
- Sharding → Horizontal scalability
- Best systems use both
-
Design choices depend on:
- Data size
- Access patterns
- Consistency requirements
- Latency goals
Top comments (0)