Managing Data Replication
1. Understanding Replication Strategies
| Strategy | Description | Examples |
|---|
| Single-leader | One leader; followers replicate | PostgreSQL, MySQL, MongoDB |
| Multi-leader | Multiple writable nodes | BDR, CouchDB, multi-region MySQL |
| Leaderless | Any replica accepts writes; quorum | Cassandra, Dynamo, Riak |
| Chain | Linear chain head→tail | FAWN, CRAQ |
2. Implementing Synchronous Replication
| Property | Value |
|---|
| Latency | Bounded by slowest replica RTT |
| Durability | Strong — survives N-1 failures if N replicas |
| Availability | Reduced — write blocks if replica down |
| Use Case | Financial records, leader logs |
3. Implementing Asynchronous Replication
| Property | Value |
|---|
| Latency | Local commit only |
| Durability | Risk of data loss on leader crash |
| Availability | High |
| Lag | Replication lag observable to readers |
4. Implementing Semi-Synchronous Replication
| Mechanism | Detail |
|---|
| At least one sync replica | Others async |
| MySQL | rpl_semi_sync_master_enabled |
| PostgreSQL | synchronous_standby_names |
| Trade-off | Balanced durability/latency |
5. Understanding Replication Lag and Staleness
| Anomaly | Cause | Mitigation |
|---|
| Read your writes failure | Read hits stale follower | Route post-write to leader; version token |
| Monotonic read failure | Reads from different replicas | Sticky session |
| Causal violation | Effect read before cause | Causal tracking |
| Unbounded lag | Slow follower | Alert on lag SLI; remove follower |
6. Implementing Read Replicas
| Pattern | Detail |
|---|
| Read split | Writes → leader; reads → followers |
| Lag-aware routing | Reject replicas exceeding lag threshold |
| Cross-region replicas | Local low-latency reads, async lag |
| Tools | ProxySQL, PgBouncer, RDS read endpoint |
7. Handling Replication Conflicts
| Resolution | Mechanism |
|---|
| Last Write Wins (LWW) | Highest timestamp wins; data loss possible |
| Multi-value (siblings) | Keep all; app reconciles (Riak, Dynamo) |
| CRDTs | Auto-merge by data-type semantics |
| Custom merge | App-specific conflict handler |
8. Implementing Conflict-Free Replicated Data Types (CRDTs)
| CRDT | Operation | Use Case |
|---|
| G-Counter | Increment-only | Page views |
| PN-Counter | Increment + decrement | Inventory |
| G-Set | Add-only | Tags |
| 2P-Set | Add + remove (no re-add) | Friends list |
| OR-Set | Add + remove with unique tags | Shopping cart |
| LWW-Register | Single value with timestamp | User profile field |
| RGA / Logoot | Sequence | Collaborative text edit |
9. Understanding Active-Active vs Active-Passive
Active-Active
- All sites serve traffic
- Better resource use
- Conflict resolution required
- Lower failover time
Active-Passive
- One active, others standby
- Idle capacity
- No conflict
- Failover detection delay
10. Implementing Chain Replication
| Aspect | Detail |
|---|
| Topology | Linear: head → middle(s) → tail |
| Writes | Sent to head, propagated to tail |
| Reads | Tail only (strong consistency) |
| CRAQ extension | Reads from any node with version check |
| Pros | Strong consistency + high read throughput |
11. Implementing Quorum Reads and Writes (R + W > N)
| Config | Read Latency | Write Latency | Use Case |
|---|
| N=3, R=2, W=2 | Medium | Medium | Default balanced |
| N=3, R=1, W=3 | Low | High | Read-heavy |
| N=3, R=3, W=1 | High | Low | Write-heavy |
| N=3, R=1, W=1 (sloppy) | Lowest | Lowest | Eventual; risk of lost updates |
Note: R + W > N guarantees overlap of read/write quorums (strong consistency on key); does NOT make multi-key ops atomic.