Week 8 — Replication Strategies

Leader-Follower (Primary-Replica)

One node accepts all writes. Followers replicate and serve reads.

All writes → Primary ──WAL──→ Replica 1 (reads)
                      ──WAL──→ Replica 2 (reads)

Failover: Replica is promoted to primary. Clients reconnect. Automated with tools like Patroni.

Sync vs Async Replication

	Synchronous	Asynchronous
Data loss on primary crash	Zero	Up to replication lag
Write latency	Higher (waits for replica ACK)	Lower
Config (PostgreSQL)	synchronous_commit = on	synchronous_commit = off

Recommendation for financial data: synchronous for critical transactions, async for analytics replicas.

Replication Lag Problems

Three subtle bugs caused by lag:

1. Read-Your-Writes

User submits a form, gets redirected, reads stale data from replica.

Fix: Route the read immediately after a write to the primary.

2. Monotonic Reads

User refreshes the page, reads from replica A (up to date), then replica B (lagging) — data appears to go backwards.

Fix: Sticky sessions — same user always reads from the same replica.

3. Consistent Prefix Reads

In distributed systems, causally related writes may arrive out of order.

Fix: Write causally related data to the same shard/partition.

Multi-Leader

Multiple nodes accept writes. Writes replicate to all other leaders.

Use cases: multi-datacenter (one leader per region for low-latency writes).

Problem: write conflicts. Same record edited on two leaders simultaneously — which wins?

Resolution strategies:

• Last-write-wins (by timestamp) — data loss risk
• Vector clocks — track causality
• CRDTs — data structures that merge automatically

For ERP/accounting: do NOT use multi-leader. Conflict resolution for financial data is dangerous.

Leaderless (Dynamo Model)

Any node accepts reads and writes. Uses quorum:

W + R > N   (where N = total replicas)
W = nodes that must confirm a write
R = nodes that must respond to a read

Example: N=3, W=2, R=2 → always at least 1 node overlap → consistency.

Examples: DynamoDB, Cassandra, Riak.

Good for: high availability, globally distributed, eventual consistency acceptable. Bad for: financial transactions needing strong consistency.

PostgreSQL + Patroni Setup

Primary → Patroni (monitors health)
        → etcd (cluster state)
        → Replica 1
        → Replica 2

On primary failure:
  Patroni detects → elects new primary → updates etcd → fences old primary
  Clients reconnect via DNS or VIP update
  Target: failover < 60 seconds

Self-check

• What is “split-brain” and why is fencing needed to prevent it?
• If you use async replication and the primary crashes, what happens to unconfirmed writes?
• Why is multi-leader a bad idea for a shared inventory system?