How does replication work and what are its strategies?

Question

Accepted Answer

**Replication** maintains copies of data across multiple servers — for **availability** (surviving failures), **read scaling** (serving reads from copies), and **geographic distribution**. Different strategies (primary-replica, multi-primary, sync vs async) involve trade-offs.

## Why replicate

```text
✓ AVAILABILITY/redundancy → if one copy fails, others have the data (no data loss, failover)
✓ READ SCALING → serve reads from replicas (offload the primary) → handle more reads
✓ GEO-DISTRIBUTION → copies near users (lower latency); disaster recovery
→ replication is fundamental to reliable, scalable data systems.
```

## Replication strategies

```text
PRIMARY-REPLICA (master-slave) → one PRIMARY handles writes, replicates to READ replicas:
  ✓ simple; great for read-heavy workloads; the common model
  ✗ the primary is a write bottleneck / single point for writes (failover needed)
MULTI-PRIMARY (multi-master) → multiple nodes accept writes:
  ✓ write availability/scaling, geo-writes  ✗ CONFLICT resolution (concurrent writes to
    the same data) → complex
```

## Synchronous vs asynchronous

```text
SYNCHRONOUS → wait for replicas to confirm before acknowledging the write:
  ✓ replicas are consistent (no data loss on failover)  ✗ slower (waits); availability impact
ASYNCHRONOUS → acknowledge the write immediately; replicate in the background:
  ✓ fast writes, high availability  ✗ REPLICATION LAG → replicas briefly behind (stale reads;
    possible data loss if the primary fails before replicating) — eventual consistency
→ trade-off: durability/consistency vs performance/availability
```

## Why it matters

Understanding replication is valuable because it's a **fundamental technique for availability and read scaling** in data systems, so it's important system-design knowledge.

Replication — maintaining copies of data across servers — serves crucial purposes: **availability** (surviving failures through redundancy and failover), **read scaling** (serving reads from replicas to offload the primary, valuable for read-heavy workloads), and **geographic distribution** (copies near users for lower latency, plus disaster recovery).

Understanding these purposes clarifies why replication is fundamental to reliable, scalable data systems.

Understanding the **strategies** — **primary-replica** (one primary for writes replicating to read replicas — the common, simple model great for read-heavy workloads, though the primary is a write bottleneck) versus **multi-primary** (multiple nodes accepting writes, enabling write scaling and geo-writes but requiring complex conflict resolution) — is necessary for choosing the right approach.

Understanding the **synchronous vs asynchronous** trade-off is particularly important: **synchronous** replication (waiting for replicas to confirm before acknowledging) keeps replicas consistent and avoids data loss but is slower, while **asynchronous** replication (acknowledging immediately, replicating in the background) is fast and highly available but has **replication lag** (replicas briefly behind, causing stale reads and possible data loss if the primary fails before replicating — eventual consistency).

This durability/consistency vs performance/availability trade-off is a key design decision.

Since replication is fundamental to availability and read scaling in data systems and the strategies (primary-replica vs multi-primary) and sync/async trade-offs significantly affect consistency, performance, and availability, and since understanding them is important for designing data systems, understanding replication is valuable, practically-relevant system-design knowledge — a fundamental technique for availability and read scaling, with important strategy and sync/async trade-offs, and central to designing reliable, scalable data systems that survive failures and handle read load.