30-Second Glance
- Replication buys availability, fault tolerance, and scalability — at the price of consistency complexity.
- Leader-based (MySQL, PostgreSQL, RDS): strong consistency and trivial conflict handling, but failover halts writes and the leader bottlenecks.
- Multi-leader (Active-Active Postgres, Multi-Master MySQL): geo-local writes for collaboration and multi-region apps, but hard conflict resolution and inconsistency risk.
- Leaderless (DynamoDB, Cassandra, Riak): no single point of failure and easy scale-out, but quorum/conflict machinery and partition weirdness.
- Chain (HBase): ordered, linearizable writes down a chain, read at the tail — at the cost of write latency and chain fragility.
Summary of Replication Techniques
Replication is a key strategy in distributed systems to enhance availability, fault tolerance, and scalability. There are several replication techniques, each with its own set of trade-offs. Here’s a summary of the main replication techniques, along with their pros and cons, and real-world examples:
1. Leader-Based Replication
Description:
- A single leader node handles all write requests and propagates changes to follower nodes.
- Followers handle read requests and apply changes received from the leader.
Pros:
- Strong consistency as writes are coordinated through the leader.
- Simple conflict resolution as only the leader handles writes.
Cons:
- Single point of failure: if the leader fails, write operations are temporarily halted until a new leader is elected.
- Can become a bottleneck if the leader is overwhelmed with write requests.
Examples:
- Databases: MySQL with InnoDB, PostgreSQL, Amazon RDS
- Applications: Financial systems, inventory management where strong consistency is critical.
2. Multi-Leader Replication
Description:
- Multiple leaders handle write requests and replicate changes to each other.
- Each leader serves a specific set of clients, and changes are asynchronously propagated to other leaders.
Pros:
- Improved write availability as multiple leaders can handle write requests.
- Useful for geo-distributed setups where leaders are closer to their clients.
Cons:
- Write Conflicts : Resolution is complex due to concurrent writes to different leaders.
- Potential for data inconsistencies if writes are not properly coordinated.
Examples:
- Databases: Active-Active PostgreSQL, Multi-Master MySQL
- Applications: Collaborative editing tools, multi-region web applications.
3. Leaderless Replication
Description:
- All nodes can accept read and write requests.
- Consistency is achieved through quorum mechanisms, where a majority of nodes must agree on an operation.
Pros:
- High availability and fault tolerance as there is no single point of failure.
- Scales well with the number of nodes.
Cons:
- Potential for inconsistencies due to concurrent writes and network partitions.
- Conflict resolution can be complex and might require additional mechanisms.
Examples:
- Databases: Amazon DynamoDB, Cassandra, Riak
- Applications: Social media platforms, content delivery networks, IoT applications.
4. Chain Replication
Description:
- Nodes are organized in a chain where writes are passed down the chain, and reads are performed at the tail of the chain.
- Ensures that writes are replicated in order.
Pros:
- Strong consistency and linearizability.
- Efficient for workloads with heavy writes and fewer reads.
Cons:
- Write latency can be high due to the sequential nature of the replication.
- If any node in the chain fails, it can disrupt the replication process.
Examples:
- Databases: Apache HBase
- Applications: High-throughput data processing applications, logging systems.
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| Leader-based replication | Strong consistency; single writer so no conflicts | Failover stalls writes; leader write bottleneck | Finance, inventory (MySQL/Postgres/RDS) |
| Multi-leader replication | Write availability; local latency per region | Write conflicts; cross-leader inconsistency | Collaborative editing, multi-region web apps |
| Leaderless replication | No SPOF; high availability; scales with nodes | Concurrent-write conflicts; partition anomalies | Social feeds, CDNs, IoT (DynamoDB/Cassandra/Riak) |
| Chain replication | Ordered writes; linearizable tail reads | Sequential write latency; any link failure disrupts the chain | Heavy-write logging/pipeline workloads (HBase) |
Interview One-Liners
Q: What does this note conclude replication is for? A: Availability, fault tolerance, and scalability — each technique trading off consistency differently.
Q: Leader-based in one line? A: One writer, strong consistency, simple conflicts — but failover pauses writes and the leader bottlenecks; e.g. MySQL/InnoDB, PostgreSQL, RDS.
Q: Multi-leader in one line? A: Every region writes locally for availability — but concurrent writes to different leaders are hard to reconcile; e.g. Active-Active Postgres.
Q: Leaderless in one line? A: Every node serves reads/writes via quorums — no SPOF and easy scale, but conflicts and partitions bite; e.g. DynamoDB, Cassandra, Riak.
Q: Chain replication in one line? A: Writes flow down an ordered chain and reads hit the tail — linearizable but sequentially slow and fragile to any link failing; e.g. HBase.
Q: Which fits a bank ledger vs a like-counter? A: Leader-based (or chain) for the ledger's correctness; leaderless for the like-counter's availability and scale.