11.4.1: Data Replication Strategies

Replication means maintaining multiple copies of data on different nodes. The strategies differ in how updates are propagated and coordinated:

• Single-Leader (Master-Slave) Replication: One node is designated as the leader (primary); all writes go to this leader, and it serializes the updates. The changes are then propagated (synchronously or asynchronously) to one or more follower (replica) nodes. Reads can be served by the leader and/or replicas (replicas may serve slightly stale data if using async replication). This is a very common strategy (used by many relational databases for high availability – e.g., one primary database with read replicas). It provides a relatively simple consistency model: consistent reads from the leader, and eventual consistency on replicas if async. If the leader fails, a failover process promotes a replica to leader. Strong consistency can be achieved if replicas confirm each write (synchronous replication) but at the cost of higher latency, or eventual consistency if writes are asynchronous for performance.
• Multi-Leader (Master-Master) Replication: Multiple nodes accept write operations, and they coordinate to replicate updates to each other. This is more complex (resolving conflicts is a key issue if the same data is written in two places at once). It can be useful for geo-distributed databases where each datacenter can accept writes (e.g., multi-region active-active setups). Some NoSQL databases (like Cassandra) treat all nodes as leaders in a sense – any node can accept a write; conflict resolution (like “last write wins” or version vectors) is used to reconcile differences. Multi-leader gives better availability (no single point to accept writes) but often sacrifices consistency or simplicity of conflict resolution. IBM Cloudant/CouchDB for instance uses a multi-primary setup where every node can accept writes and conflicts are resolved via revision histories. This maximizes availability and partition tolerance (in CAP terms, Cloudant chooses AP: Availability and Partition tolerance at the cost of immediate consistency).
• Quorum-based Replication (Dynamo-style): In systems like Amazon Dynamo, Cassandra, and many quorum-based stores, each data item is replicated to N nodes. On a write, the system requires acknowledgment from at least W nodes (a write quorum) before considering it successful; on a read, it will query R nodes for the latest value (a read quorum). If W + R > N, you get a condition where the latest write and read sets overlap, thereby ensuring the read will see at least one copy of the latest write – this is how you achieve strong consistency at read time if desired. However, often these systems use settings for eventual consistency (e.g., Dynamo’s default might be W=1, R=1 for speed, meaning it doesn’t guarantee the latest read). Quorum systems allow tuning the consistency level per operation – for example, Cassandra clients can request ALL replicas ack a write for strong consistency, or just ANY for lower latency at the cost of consistency.
  

• Geo-Replication and Multi-Region Replication: Cloud providers often offer multi-region replication modes. For example, Amazon S3 cross-region replication will asynchronously copy objects from a bucket in one region to another for disaster recovery or latency reduction (this is asynchronous, so if a user in region A updates an object, a user in region B might see the old version for some time until replication completes). In databases, Aurora Global Database replicates data from a primary region to secondary read-only regions with typically <1 second lag, offering fast reads globally but writes still funnel to primary (thus preserving consistency at the cost of some latency for far-flung users). Cosmos DB allows multiple writable regions and offers five consistency levels – from strong (linearizable across regions) to eventual – letting developers choose the trade-off between latency and consistency for geo-distributed apps.

Each replication strategy must consider failures and network partitions: what happens if replicas can’t communicate? Single-leader systems may sacrifice availability (if the primary is down or partitioned, you might accept downtime or read-only mode until it’s resolved to avoid inconsistency). Multi-leader or leaderless systems sacrifice some consistency (allowing divergent changes that must be reconciled later) to remain available.

Synchronous vs Asynchronous replication: If replication is synchronous, the leader waits for replicas to confirm before committing a transaction – this ensures a strong consistency (no transaction is lost even if leader fails immediately after) but can reduce throughput and increase latency (the user has to wait for multiple nodes I/O). Asynchronous means the leader replies to client after writing to its own storage, and replication happens in background – this is high-performance but can lose some recent transactions if the leader crashes before replicas got them, and yields eventual consistency on secondaries. Many systems compromise by synchronous replication across AZs for durability but asynchronous to distant regions.

---