Recap — Replication Topologies and Consistency

# Replication Topologies and Consistency Replication = keep multiple copies of data on different machines. Why: read scaling, fault tolerance, geographic distribution. ## Topologies ### 1. Master-slave (single leader) One node accepts writes; others are read replicas. ``` Writes → [Master] → replication → [Slave 1] [Slave 2] [Slave 3] Reads ← Slave (or Master, depending on freshness needs) ``` Pros: simple; consistent reads from master; scale reads via slaves. Cons: master is bottleneck for writes; slave lag (replication isn't instant). Most SQL DBs default to this (Postgres, MySQL). ### 2. Multi-master (multi-leader) Multiple nodes accept writes; changes replicate between them. ``` Writes → [Master A] ⇆ [Master B] ⇆ [Master C] ``` Pros: write scaling; geographic write locality. Cons: write conflicts (two regions update same row); complex conflict resolution. Used in: some Cassandra deployments, multi-region active-active setups. ### 3. Leaderless (peer-to-peer) No designated leader; clients write to N nodes; read from R nodes. ``` Write → quorum of W nodes Read → quorum of R nodes ``` If W + R > N, reads see latest writes (quorum overlap). Example: Cassandra, DynamoDB (in some modes). Pros: no SPOF; fault-tolerant; tunable consistency. Cons: must understand quorum trade-offs; conflicts via vector clocks or last-write-wins. ## Replication: sync vs async ### Synchronous replication Write returns only after replica acknowledges. Pros: no data loss on master failure (replica has it). Cons: write latency = max replication latency; replica failure stalls writes. ### Asynchronous replication Write returns after master writes; replication happens in background. Pros: fast writes. Cons: data loss possible if master dies before replication. ### Semi-synchronous At least one replica acks before write returns; others async. Compromise: lose only if master AND that replica both die. ## CAP theorem In a distributed system, you can have AT MOST 2 of: - **C**onsistency: all nodes see the same data at the same time. - **A**vailability: every request gets a response (success or failure). - **P**artition tolerance: system works despite network failures between nodes. In real distributed systems, network partitions WILL happen. So you must choose: - **CP**: consistent but may refuse requests during partitions (e.g., MongoDB with strong consistency, Spanner). - **AP**: available but may return stale data (e.g., Cassandra, DynamoDB default). CA is theoretical (no partition tolerance). Single-machine DBs are "CA" because there's no partition. ## PACELC (refined CAP) Daniel Abadi's extension: - During **P**artitions, choose **A** vs **C**. - **E**lse (normal operation), choose **L**atency vs **C**onsistency. Because even without partitions, replication has latency cost for consistency. Most systems trade some consistency for lower latency in normal operation. ## Consistency models Beyond strong/weak — many flavors: ### Strong consistency Reads always see the most recent write. Tools: linearizable databases (Spanner, FoundationDB with proper config). Cost: high (must coordinate or wait for replication). ### Eventual consistency Reads may see stale data; eventually all replicas converge. Tools: Cassandra (default), DynamoDB (default), DNS. Cost: low; pragmatic for many workloads. ### Read-your-writes consistency A user's own writes are immediately visible to that user. Implementation: route reads to master for some window after a write, or include user's version in their session. Common need: user updates profile → immediately wants to see it. ### Monotonic reads Once you read X version, subsequent reads see X or newer (never older). Implementation: pin user's session to one replica. ### Causal consistency Causally related operations seen in order; unrelated ones may be reordered. Mid-strength model; useful for social feeds (your comment appears after the post it replies to). ## Practical patterns ### Read from master after write ```python def update_user(user_id, data): db_master.update(user_id, data) cache_user_recently_modified(user_id, ttl=5) def get_user(user_id): if was_recently_modified(user_id): return db_master.read(user_id) # fresh read return db_replica.read(user_id) # eventual consistency OK ``` Read-your-writes via session affinity to master. ### Quorum reads/writes ```python N = 3 # replicas W = 2 # write quorum R = 2 # read quorum # W + R > N → quorum overlap → strong consistency ``` DynamoDB and Cassandra expose these as tunable parameters per query. ## Common replication mistakes 1. **Reads from replica without considering lag.** Read-your-writes anomaly. 2. **Multi-master without conflict-resolution strategy.** Lost writes. 3. **Synchronous replication blindly.** One slow replica stalls everything. 4. **Strong consistency when eventual would do.** Pays unnecessary latency. 5. **Eventual consistency when strong