Skip to content

Replication

1. What is it? (2-3 lines)

Replication is the process of copying and maintaining data across multiple physical or virtual nodes in a network, ensuring high availability, fault tolerance, and read scalability.

2. Why does it exist?

Single-node databases are single points of failure (SPOF) and bounded by a single machine's CPU, RAM, and disk read capacity. Replication guarantees that if a primary database node crashes, a secondary replica can instantly take over (High Availability) while scaling read operations across replica nodes.

3. Where is it used?

  • Single-Leader (Active-Passive): PostgreSQL, MySQL, MongoDB, Redis (Primary-Replica).
  • Multi-Leader (Active-Active): Multi-region databases, CouchDB.
  • Leaderless (Peer-to-Peer): Apache Cassandra, Amazon DynamoDB.

4. Decision Matrix

Replication Topology Write Path Read Path Conflict Handling Scalability Use Case
Single-Leader 1 Primary Node All Replicas None (Single writer) High Reads; Low Writes Standard RDBMS, Web APIs
Multi-Leader Any Local Leader Local Replica Complex (CRDTs / LWW / Vector Clocks) High Write/Read across Datacenters Multi-Region Active-Active Apps
Leaderless Quorum (\(W\)) Quorum (\(R\)) Read Repair / Hinted Handoff Extremely High Writes/Reads High-Throughput NoSQL (Cassandra)

5. Replication Sync Modes

  • Synchronous: Primary waits for replica ACK before committing. Zero data loss, but high write latency.
  • Asynchronous: Primary commits immediately; replicates in background. Sub-millisecond write latency, but risks data loss during primary crashes.
  • Semi-Synchronous: Primary waits for at least 1 replica ACK (MySQL default).

6. Limitations

  • Replication Lag: Asynchronous replicas lag behind primary, causing Stale Reads (violates read-your-own-writes consistency).
  • Split-Brain Risk: Un-coordinated failover during network partitions can result in two nodes claiming to be primary.

7. Common interview questions (10)

  1. Explain the operational differences between Single-Leader, Multi-Leader, and Leaderless Replication.
  2. What is Replication Lag and how does it cause stale read anomalies in read-heavy architectures?
  3. How does Read-Your-Own-Writes Consistency solve stale read issues for a user updating their profile?
  4. What is the difference between Statement-Based, WAL-Based, and Logical Row-Based Replication?
  5. How does Semi-Synchronous Replication strike a balance between latency and durability?
  6. What is Split-Brain in Leader replication and how do Fencing Tokens or Quorum prevent it?
  7. How does MySQL InnoDB use Binary Logs (binlog) for GTID-based replication?
  8. How does PostgreSQL physical streaming replication differ from logical replication?
  9. What happens during a Primary node crash under Asynchronous Replication (Failover & Data Loss)?
  10. How do Multi-Leader architectures resolve concurrent write conflicts across datacenters?

8. Common misconceptions

  • Misconception: Replication replaces database backups. Fact: Replication mirrors accidental DROP TABLE commands instantly to all replicas! Backups preserve historical point-in-time state.
  • Misconception: Adding read replicas increases write throughput. Fact: Read replicas only scale READ capacity; write throughput remains bounded by the single Primary leader.

10. 30-second cheat sheet

  • Single-Leader: All writes to 1 Primary. Replicas scale Reads. Easy, standard, active-passive.
  • Multi-Leader: Writes to local leaders in multi-region setups. Complex conflict resolution.
  • Leaderless: Quorum (\(R + W > N\)). High availability and write throughput (Cassandra).
  • Sync vs Async: Sync = Durability (\(0\) data loss, slow); Async = Speed (fast, potential data loss).
  • Rule of Thumb: For user updates, use Read-Your-Own-Writes (route user's own reads to Primary for 5s after write).