Replication and Consistency

Replication and Consistency

Replication copies data to multiple nodes to provide fault tolerance and read scalability. The trade-off is managing consistency across replicas.

Leader-Follower Replication

One leader (primary) accepts all writes; followers (replicas) receive writes via replication log and serve reads.

        Writes          Reads
          ↓               ↓
┌─────────────────┐    ┌──────────┐
│    Leader       │───→│ Follower │
│   (Primary)     │    │    1     │
└─────────────────┘    └──────────┘
          │            ┌──────────┐
          └───────────→│ Follower │
                       │    2     │
                       └──────────┘

Pros:

• Simple to understand and implement
• Read scaling: add followers for more read capacity
• Automatic failover: promote a follower to leader on failure

Cons:

• Write bottleneck: all writes go to one leader
• Replication lag: followers may be behind the leader

Multi-Leader Replication

Multiple nodes accept writes. Used in multi-datacenter deployments.

  DC East                   DC West
┌──────────┐               ┌──────────┐
│ Leader 1 │◄─────────────►│ Leader 2 │
└──────────┘  async sync   └──────────┘

Pros: Write availability even if one DC goes down. Cons: Write conflicts when both leaders modify the same data.

Conflict resolution strategies:

• Last Write Wins (LWW): highest timestamp wins (may lose data)
• Merge: application merges conflicting versions
• CRDT: data structures that merge automatically

Replication Lag and Consistency Issues

Scenario (replication lag = 2 seconds):

1. User updates profile photo
2. Write → Leader
3. User refreshes page → Read routes to Follower
4. Follower is 2 seconds behind → user sees old photo!

↑ This is a "read-after-write" consistency violation

Solutions for read-after-write consistency:

// Option 1: Route reads to leader for data you just wrote
public UserProfile getProfile(String userId, boolean justUpdated) {
    if (justUpdated) return leaderDb.findById(userId); // always consistent
    return followerDb.findById(userId); // may lag
}

// Option 2: Timestamp-based routing
// Read from leader if write was within last 5 seconds
// else read from follower

// Option 3: Wait for replication before returning
// Synchronous replication: wait for N replicas to confirm write

Synchronous vs Asynchronous Replication

Semi-synchronous: one follower is synchronous; others async. Good balance.

Replication Topologies

• Single-leader: one leader, many followers (most common)
• Multi-leader: multiple leaders (multi-DC)
• Leaderless (Dynamo-style): any node can accept writes; quorum consistency

Quorum: with N replicas, write to W nodes, read from R nodes. If W + R > N, reads always see most recent write.

N=3, W=2, R=2: W+R=4 > 3 → strong consistency
N=3, W=1, R=1: W+R=2 ≤ 3 → eventual consistency (higher availability)

Interview Tips

1. Leader-follower is the default — mention it for databases in system design, then address the lag problem.
2. Know the read-after-write consistency problem — it comes up in social media (post something, refresh, post is gone).
3. Mention quorum-based reads/writes when discussing Cassandra, DynamoDB, or Riak.