Database Replication

Replication copies data from one database server to others so the same data lives on multiple nodes. This improves availability, spreads read load, and protects against data loss when a node fails.

1. Learning Objectives

In this lesson, you will master the principles of database replication. By the end of this module, you will be able to:

• Evaluate the trade-offs between Single-Leader, Multi-Leader, and Leaderless replication topologies.
• Differentiate between synchronous, asynchronous, and semi-synchronous replication mechanics.
• Identify and mitigate replication lag anomalies including read-after-write, monotonic reads, and consistent prefix reads.
• Describe conflict resolution strategies (e.g., LWW, CRDTs, Vector Clocks) in multi-leader and leaderless systems.
• Design failover protocols and analyze the risks of split-brain in leader election.

2. Prerequisites

To get the most out of this lesson, you should be familiar with:

• Databases and DBMS basics: How storage engines write to disk (B+ Trees, Write-Ahead Logs).
• The CAP and PACELC Theorems: Understanding consistency versus availability, and latency versus consistency.
• Networking basics: RPCs, network partitions, and socket-based communications.

3. Why This Topic Matters

A single database node is a single point of failure (SPOF) and is physically limited in capacity. If the database crashes, your application goes offline. If millions of users query your database simultaneously, disk I/O bottlenecks degrade latency. Replication solves these bottlenecks by distributing copies of the data across multiple machines. It is the core technique that enables high-scale websites (like Netflix or Amazon) to serve reads locally with sub-millisecond latencies, withstand datacenter outages without data loss, and maintain horizontal read scalability. In system design interviews, understanding the edge cases of database replication—specifically, how to handle consistency anomalies and split-brain scenarios—is a primary discriminator for senior engineering positions.

4. Real-world Analogy

Imagine a popular global newspaper headquartered in New York. The chief editor creates the articles and formats the main issue (the Primary/Leader Node). If the newspaper only printed physical pages in New York and mailed them to readers in Tokyo, London, and Sydney, it would take days for global readers to get their news (high latency), and if the New York office flooded, the entire global distribution would halt (Single Point of Failure).

To solve this, the newspaper sets up printing presses and local distribution centers in Tokyo, London, and Sydney (Replica/Follower Nodes). Every night, the New York headquarters sends the digital draft of the articles to the international locations. The local offices print the newspaper locally and deliver it to readers in their respective regions (Read Scaling). However, this introduces challenges:

• Replication Lag: If New York publishes a breaking news correction at 11:55 PM, and the Tokyo printing press starts printing at 11:50 PM, Tokyo readers will read the old article for the day.
• Consistency Model: If the New York office prints synchronously, they must wait for Tokyo, London, and Sydney to confirm they received the file before declaring the edition finalized (high reliability, high latency). If they print asynchronously, New York publishes immediately, but other offices catch up at their own pace.

5. Core Concepts

Database replication strategies are defined by who accepts writes, how fast updates are synchronized, and how data changes are serialized.

Replication Topologies

• Single-Leader (Primary-Replica): All write requests are sent to a single designated node (the primary/leader). The leader writes to local storage and streams updates to read-only replicas (followers). Clients read from any node, scaling read capacity.
• Multi-Leader (Active-Active): Multiple nodes act as leaders, accepting write requests. They replicate their writes to each other. This is useful for multi-datacenter operations to reduce write latency and handle datacenter outages, but it introduces write conflicts.
• Leaderless (Dynamo-Style): There is no centralized leader. Writes and reads are sent to multiple nodes in parallel. Consensus is achieved using quorums ($W + R > N$, where $W$ is write quorum, $R$ is read quorum, and $N$ is the replication factor). Popularized by Amazon Dynamo, Cassandra, and Riak.

Replication Methods

• Synchronous Replication: The leader waits for all replicas (or a subset) to write the change to their local logs before responding "Success" to the client. This guarantees zero data loss (strong consistency) but makes the write latency equal to the slowest replica.
• Asynchronous Replication: The leader records the write locally and immediately returns "Success". The change is propagated to replicas in the background. Latency is extremely low, but if the leader crashes before propagating a write, that write is lost.
• Semi-Synchronous Replication: A compromise where the leader waits for at least one replica to write the change to its log before acknowledging the client. If that replica is up to date, data loss is prevented even if the leader goes offline.

Replication Log Formats

• Statement-Based: The leader logs the raw SQL queries (e.g., UPDATE users SET age = age + 1 WHERE id = 5) and sends them to replicas. Replicas run the queries. Limitation: Non-deterministic statements (like NOW(), RAND(), or auto-incrementing IDs) can lead to data divergence.
• Write-Ahead Log (WAL) Shipping: The leader sends the exact byte changes (physical disk blocks modified) to replicas. Replicas write these blocks directly to disk. Limitation: Highly coupled to the database storage engine version; makes upgrading the database software version difficult without downtime.
• Logical Log Replication (Row-Based): The log contains record modifications (e.g., "Row updated in table Users: id=5, old_age=25, new_age=26"). Replicas process these changes. It decouples replication from storage engine internals, allowing replication between different database versions or even different database engines.

6. Visualization

The diagram below demonstrates the difference in client latency and database consistency guarantees between synchronous and asynchronous replication models:

7. How It Works

Let us detail the step-by-step request-response and synchronization lifecycle in a typical Primary-Replica (Leader-Follower) database replication system:

Replication Lifecycle

1. Initial Snapshot Creation: When setting up a new replica, the primary database creates a point-in-time snapshot of the database state. This allows the primary to continue writing to files without locking the database.
2. Log Sequence Tracking: The snapshot is stamped with a Log Sequence Number (LSN) or transaction ID (e.g., GTID). The replica is loaded with the snapshot and starts with this baseline position.
3. Connection & Handshake: The replica establishes a long-lived TCP connection to the primary and requests the replication stream beginning at its local LSN.
4. Streaming Changes: Whenever the primary executes a transaction, it writes changes to its local Write-Ahead Log (WAL). A background replication thread detects new entries in the WAL and pushes them down the socket connection to the replica.
5. Local Buffering (Relay Log): The replica receives the byte stream, immediately writing it to a local cache file, often called a Relay Log, to decouple network reception from physical write application.
6. Applying Modifications: An applier thread reads the changes sequentially from the relay log, updating the replica's local data pages and indexes.
7. Heartbeats & Keepalives: The nodes exchange lightweight health-check packets at periodic intervals (e.g., every 1 second). If a heartbeat fails to arrive within a timeout window (e.g., 10 seconds), the system marks the connection dead and initiates reconnection or failover procedures.

8. Internal Architecture

A replicated database runs several internal modules to manage log streams, track positions, and coordinate replica health. Below is the structural layout of these components:

9. Request Lifecycle

Let us trace the absolute path of reads and writes in a Single-Leader architecture with one Primary and two Read Replicas (one Sync, one Async):

Write Request Path

1. The Client Application connects to the primary node and submits a write command: INSERT INTO users (id, name) VALUES (10, 'Alice');
2. The Primary parser parses, compiles, and locks row id = 10. It writes the physical transaction details to the local Write-Ahead Log (WAL) and commits the change to its memory page buffers.
3. The Primary's replication module detects the write. It streams the transaction record to the Sync Replica and the Async Replica.
4. The Sync Replica receives the log, flushes it to its local Relay Log, and immediately returns a success signal to the Primary.
5. The Primary, having written to its local WAL and received confirmation from the Sync Replica, commits the transaction and sends a success status back to the Client.
6. The Async Replica receives the log stream at its own pace, flushes it, and applies it to its tablespace files asynchronously.

Read Request Path

1. The Client Application wants to read Alice's record: SELECT * FROM users WHERE id = 10;
2. If the client application requires strong consistency (e.g., read-your-own-writes), the client routing layer directs the query to the Primary node.
3. If the client application only requires eventual consistency (e.g., loading public profiles), the routing layer routes the query to one of the Read Replicas (using round-robin or least-connections load balancing).
4. If the read hits the Sync Replica, it is guaranteed to return Alice's record. If it hits the Async Replica and there is a network partition or heavy replica lag, the query might return null or stale data.

10. Deep Dive

To build reliable systems, we must address replication lag anomalies, handle conflicts in multi-write architectures, and manage consensus-driven failover.

Replication Lag Anomalies

When reads are routed to asynchronous replicas, replication lag (the delay between a write on the primary and its application on a replica) can cause severe user experience bugs:

• Read-Your-Own-Writes Consistency (Read-After-Write):

  Anomaly: A user updates their profile photo. The write goes to the Primary. The page reloads, and the read request is routed to a lagging Async Replica. The user sees their old photo and assumes the upload failed, prompting them to retry unnecessarily.

  Mitigations: Direct reads of user-owned profile fields to the Primary node. Alternatively, track the user's last write timestamp in a client cookie or session state; route reads to replicas only if their replication position (LSN) is newer than the user's last write timestamp.

• Monotonic Reads:

  Anomaly: A user refreshes a comment section. The first request hits Replica A (which has caught up to LSN 100), displaying 10 comments. The second refresh hits Replica B (which is lagging at LSN 80). The user sees only 5 comments. To the user, it feels as if time has run backward.

  Mitigations: Guarantee that a single user's read requests are pinned to the same replica. This can be done by routing reads using a hash of the user ID (session affinity), ensuring that if the replica is lagging, at least it doesn't fluctuate backward in time.

• Consistent Prefix Reads:

  Anomaly: In a chat application, Alice writes "Are you there?" (Transaction 1) and Bob replies "Yes, I am!" (Transaction 2). If these transactions are routed over different databases, a third user (Charlie) reads from a replica that has applied Bob's reply but has not yet applied Alice's question. Charlie sees: "Yes, I am!" followed minutes later by "Are you there?". This violates causal order.

  Mitigations: Ensure causally dependent updates are routed to the same partition/leader so they are serialized together. This is a common design pattern in sharded systems using routing keys.

Multi-Leader Write Conflict Resolution

When multiple leaders accept writes on the same row concurrently, conflicts are inevitable. Systems resolve these conflicts using several models:

• Last-Write-Wins (LWW): Every write is stamped with a wall-clock timestamp. The write with the latest timestamp is preserved, while older writes are dropped. Risk: Because physical server clocks are never perfectly synchronized (clock skew), LWW can silently discard valid writes.
• Conflict-Free Replicated Data Types (CRDTs): Specialized data structures (like G-Counters, PN-Counters, or LWW-Element-Sets) that merge mathematically without requiring consensus. For instance, a PN-Counter allows additions and subtractions to merge commutatively regardless of arrival order.
• Vector Clocks: A logical clock tracking version numbers across nodes. Vector clocks do not tell you the exact time, but they identify whether one write happened before another, or if they occurred concurrently. If concurrent, the system returns both versions to the application client to resolve manually (e.g., Amazon's shopping cart merge).

Replica Failover and Split-Brain

When the primary node crashes, the cluster must promote a replica to be the new primary. This failover process is handled via two methods:

• Manual Failover: An engineer receives an alert, checks node health, stops replication, promotes a replica, and updates application database configs. Safe but slow.
• Automatic Failover: A health-checking coordinator (like ZooKeeper or Consul) detects the leader is dead (heartbeat timeout). It holds an election among the remaining replicas. The replica with the most up-to-date LSN is promoted.

The Split-Brain Danger: If a network partition isolates the Primary from the rest of the cluster, the replica pool might assume the primary is dead and elect a new primary. However, the old primary might still be healthy and accepting writes from clients on its side of the network. If both nodes accept writes, the database will diverge irreconcilably. To mitigate this, databases use Quorums: a node is not allowed to accept writes or elect a leader unless it can communicate with a strict majority (>50%) of the cluster nodes.

11. Production Example

Case Study: AWS Aurora Storage Replication

Traditional databases (like standard MySQL) replicate by sending physical WAL files over network sockets to replicas. Replicas then replay those WAL files locally, causing disk write bottlenecks on the replicas. AWS Aurora took a fundamentally different approach by separating the compute layer from the storage layer.

• Log-Structured Storage Engine: Aurora's database instances do not write physical pages to disk. Instead, they send Write-Ahead Log (WAL) streams directly to a shared, distributed storage fleet.
• 6-Way Replication: Aurora replicates every log write to 6 storage nodes spread across 3 Availability Zones (AZs) (2 replicas per AZ).
• Quorum Writes and Reads:
  • Write Quorum ($4/6$): A write is acknowledged to the client as soon as 4 out of the 6 storage nodes confirm they have written the log record. This makes the database tolerant to the loss of an entire AZ plus one additional node without write disruption.
  • Read Quorum ($3/6$): Replicas do not need to fetch data blocks from the database instance; they read directly from the shared storage fleet. Reads are fast because they query the storage nodes to retrieve the latest block versions.
• No Log Replay on Replicas: Replicas in Aurora do not have to write data blocks or replay logs. They only receive metadata updates (log sequence numbers) to update their local memory buffers (buffer pool cache), eliminating the write-bottleneck on read-replicas.

12. Advantages

• Read Scalability: By sending read queries to multiple read-only replicas, we offload reads from the primary node.
• High Availability: If one replica fails, other replicas continue serving reads. If the primary fails, a replica can be promoted.
• Geographic Locality: Replicas placed in different physical regions (e.g., US, Europe, Asia) allow clients to query databases locally, reducing latency.
• Safe Database Backups: Running database backups consumes massive disk I/O. By executing backups on a replica, we keep the primary node free of backup-related resource contention.

13. Limitations

• No Write Scalability: In Single-Leader systems, all write requests must still go to the single primary node. Scaling writes requires Sharding (partitioning data).
• Replication Lag and Consistency Issues: Applications must handle stale reads and resolve inconsistent records at the application layer.
• Increased Infrastructure Costs: Running multiple instances increases network transfer costs (especially cross-AZ/cross-region) and disk storage costs.
• Operational Complexity: Handling failover, configuring connection routers, monitoring replication lag, and upgrading multi-node systems is complex.

14. Trade-offs

Consistency vs. Availability (CAP Theorem)

During a network partition:

• If you choose Consistency (CP), you must disable writes to isolated nodes until the partition heals, sacrificing availability.
• If you choose Availability (AP), nodes on both sides of the partition will continue accepting writes, leading to eventual consistency and write conflicts.

Consistency vs. Latency (PACELC Theorem)

Even when there are no partitions (Else):

• If you prioritize Consistency (C), you must write synchronously to multiple replicas, increasing write latency.
• If you prioritize Latency (L), you write asynchronously, risking stale reads and data loss during crashes.

15. Performance Considerations

• Network Bandwidth & Cross-Region Costs: Continuous streaming of high-write databases creates high network traffic. Grouping or compressing WAL segments reduces bandwidth but increases CPU utilization.
• Replica Disk Bottlenecks: If a replica runs on slower disk drives or shares hardware, the Applier Thread will fall behind. Ensure replicas have identical disk I/O performance (IOPS) to the primary.
• Connection Routing Overhead: Dynamic routing of reads/writes requires a middleware proxy (e.g., ProxySQL for MySQL or PgBouncer with custom routing logic). Ensure the proxy doesn't become a latency bottleneck.

16. Failure Scenarios

Scenario A: Primary Node Sudden Crash (Failover Loss)

Problem: The Primary crashes while using asynchronous replication. The promoted replica is missing the last 150 transactions because they had not yet streamed over the network.

Resolution: The coordinator promotes the replica anyway to restore writes. The old primary, upon recovery, must not rejoin as primary (split-brain). It must be demoted to a replica. Any un-replicated writes are typically discarded or saved to a separate "recovery table" to be resolved manually.

Scenario B: Replica Lag Avalanche

Problem: A heavy batch insert job runs on the Primary. The primary handles writes in parallel threads, but the Replica processes writes using a single thread. The replica lag grows from 1 second to 45 minutes, rendering reads from the replica uselessly stale.

Resolution: Configure multi-threaded, parallel replication. Also, set up routing rules to remove a replica from the load balancer if its replication lag exceeds a safe threshold (e.g., 5 seconds).

Scenario C: Split-Brain after Coordinator Isolation

Problem: A network partition isolates the Primary node from the coordinator nodes. The coordinator assumes the Primary is dead and promotes a Replica. The client router still routes writes to the old Primary due to cached DNS/IP routing rules, resulting in dual primaries.

Resolution: Implement Fencing mechanisms. The database must use STONITH ("Shoot The Other Node In The Head") or lock systems to physically power down or revoke access tokens from the old primary before promoting a new leader.

17. Best Practices

• Use GTID (Global Transaction Identifiers): Always enable GTIDs instead of relying on file names and offset positions (e.g., mysql-bin.000003 at offset 402). GTIDs make it simple to point replicas to a new primary node during failovers.
• Enforce Read-Only Mode on Replicas: Set the database config (e.g., read_only = ON) on replicas. This prevents applications or rogue queries from writing directly to replicas, which immediately causes data divergence.
• Monitor Replication Lag Metrics: Create automated alerts on metrics like PostgreSQL's pg_wal_lsn_diff or MySQL's Seconds_Behind_Master. Remove lagging nodes from read pools.
• Enable Parallel Replication: Modern databases support parallel thread execution for applying log entries. Group updates by schema or table hash to run safe concurrent updates on replicas.

18. Common Mistakes

• Relying on Statement-Based Replication with Non-Deterministic Logic: Using functions like UUID(), RAND(), or NOW() will cause databases to store different values on the primary and replica. Always use Row-Based or Mixed-Format logging in production.
• Executing Long-Running Queries on Replicas: Running massive analytical reports on a read-replica can lock tables or exhaust disk space, blocking the replication Applier Thread and causing the replica to fall behind indefinitely.
• Using Asynchronous Replicas for Read-Your-Own-Writes: Assuming that redirecting a user back to their profile immediately after updating it will work fine. Without enforcing Primary reads or session affinity, users will complain that their updates are lost.

19. Implementation (Only If Applicable)

Below is a complete, working Python simulation of a Single-Leader Replication System. It implements both Synchronous and Asynchronous replication modes, simulates network latency, and demonstrates replication lag anomalies when reading from lagging replicas.

20. Interview Questions

Easy Question

Q: What is the main difference between synchronous and asynchronous database replication?

A: In synchronous replication, the primary node writes locally and waits for all replicas (or a quorum) to write the transaction to their logs before sending a success status back to the client. This guarantees strong consistency and zero data loss on primary failure, but increases write latency. In asynchronous replication, the primary node returns a success status immediately after committing locally and streams the update to replicas in the background. This provides minimal write latency but risks data loss if the primary crashes before updates are successfully transmitted.

Medium Question

Q: How would you solve the 'Read-Your-Own-Writes' consistency anomaly in a system that uses asynchronous read-replicas?

A: You can solve this using two common strategies:

• Routing Rules: Route queries for data that the user has the privilege to modify (such as their own user profile details) exclusively to the Primary node. Route public or read-only data (other users' profiles) to the replicas.
• Logical Lag Tracking: Store the timestamp or the Transaction LSN of the user's last write in their session (e.g., in a cookie or JWT). When the user submits a read request, route the query to a replica only if the replica's last applied LSN is greater than or equal to the session's write LSN. If no replicas are caught up, force the query to run on the primary.

Hard Question

Q: What is Split-Brain, and how does quorum-based leader election prevent it in distributed database clusters?

A: Split-brain occurs when a network partition divides a database cluster into two isolated sub-networks. If both sides assume the other is dead, a replica on the isolated side may be promoted to primary, while the original primary is still active on its side. Clients on both sides of the partition will write to different primaries, creating divergent datasets.

To prevent this, clusters use quorums. A new leader can only be elected, and writes can only be accepted, if a node can communicate with a strict majority of nodes (quorum $Q = \lfloor N/2 \rfloor + 1$). Since a network partition can only leave at most one side with a strict majority, only the majority partition can elect a new leader. The minority side will recognize that it lacks quorum, disable writes, and prevent split-brain.

21. Practice Exercises

Easy Exercise

Determine the minimum number of physical replication nodes needed to tolerate up to two simultaneous node crashes without losing availability in a quorum-based leaderless database system.

Medium Exercise

An application uses statement-based replication. Explain the data corruption risk of executing the query: UPDATE orders SET status = 'EXPIRED' WHERE updated_at < NOW() - INTERVAL '1 day'; on the primary database, and design a logical schema change or row-based logging strategy to avoid this issue.

Hard Exercise

Design a detailed failover runbook for a Primary-Replica cluster using Raft consensus. Trace how to safely transition a replica to primary and how to run fencing operations (like STONITH) to ensure the crashed primary cannot rejoin as a leader when it boots back up.

22. Challenge Problem

Scenario: You are the lead system architect of a global ride-hailing app (like Uber). You store active driver coordinates in a MySQL database. Writes occur every 3 seconds per driver, and passenger search requests execute reads 100 times more often than driver updates. You set up a multi-region deployment (US-East, US-West, and EU-Central) with cross-region read-replicas to serve local queries.

Task: Design a replication, routing, and caching strategy that handles the massive driver coordinate write load without overloading the primary database in US-East, while guaranteeing that passengers looking for a ride in Berlin (EU-Central) do not see drivers that are actually offline or located in Chicago. List all replication lag mitigation techniques and detail how you will handle network isolation of the EU-Central region.

23. Summary

Database replication copies data across multiple nodes to eliminate single points of failure, provide read scaling, and minimize geographical latencies. The primary architectural setups are Single-Leader, Multi-Leader, and Leaderless. Synchronous replication prioritizes consistency but introduces latency overhead, whereas asynchronous replication prioritizes latency but introduces replication lag anomalies like stale reads. Managing replication lag requires robust session pinning, transaction coordinate tracking, or database routing proxies.

24. Cheat Sheet

25. Quiz

1. Which replication topology is most vulnerable to write conflicts?
   • A) Single-Leader with synchronous replicas
   • B) Single-Leader with asynchronous replicas
   • C) Multi-Leader
   • D) Leaderless with strict quorum ($W + R > N$)

   Answer: C - Multi-Leader allows multiple nodes to accept writes concurrently on the same rows, leading to write conflicts.

2. What anomaly is mitigated by ensuring a user's session reads from the same replica node?
   • A) Write conflict
   • B) Non-monotonic reads
   • C) Split-brain
   • D) Cascading failover

   Answer: B - Non-monotonic reads occur when a user reads from a caught-up replica, then a lagging replica. Pinning a session to one replica ensures reads do not go backward in time.

3. In a leaderless system with a replication factor of $N=5$, which quorum configuration guarantees strong consistency?
   • A) $W=2, R=2$
   • B) $W=3, R=2$
   • C) $W=1, R=4$
   • D) $W=3, R=3$

   Answer: D - Strong consistency requires $W + R > N$. Here $3 + 3 = 6 > 5$. (Note: $W=3, R=2$ is not strictly greater than 5).

4. What logging format is most vulnerable to data divergence when using non-deterministic SQL functions?
   • A) Physical WAL shipping
   • B) Row-based logging
   • C) Logical logging
   • D) Statement-based logging

   Answer: D - Statement-based logging replicates the raw SQL. If it contains non-deterministic functions (like RAND()), the replica will generate different data than the primary.

5. What is the purpose of a STONITH fencing mechanism?
   • A) Clean up dead tuples in MVCC
   • B) Force synchronous replication to complete
   • C) Power down or isolate an old primary to prevent split-brain
   • D) Buffer incoming database writes

   Answer: C - STONITH ("Shoot The Other Node In The Head") physically disables an old primary to ensure it cannot accept writes after a network partition resolves.

6. How does AWS Aurora optimize read replica performance compared to standard MySQL?
   • A) Replicas don't write data blocks or replay logs; they share the same physical storage fleet.
   • B) Aurora uses multi-leader write routing.
   • C) Aurora disables transaction logs entirely on replicas.
   • D) Replicas run statement-based replication.

   Answer: A - Aurora uses a shared storage architecture where replicas do not execute log replays; they read blocks directly from the storage tier.

7. What is the primary drawback of using Vector Clocks in leaderless databases?
   • A) They require highly synchronized atomic clocks.
   • B) They can grow excessively in size as the number of nodes in the cluster increases.
   • C) They do not support concurrent writes.
   • D) They only work with SQL schemas.

   Answer: B - Vector clocks track version increments across every writing node, meaning they grow with the size of the cluster, requiring vector clock pruning.

8. Which replication method guarantees zero data loss on primary crash but can cause write operations to block if replicas fail?
   • A) Asynchronous Replication
   • B) Synchronous Replication
   • C) Logical Replication
   • D) Row-Based Replication

   Answer: B - Synchronous replication requires the replica to confirm the write before returning success. If the replica goes offline, writes on the primary block.

9. How does Semi-Synchronous replication differ from Synchronous replication?
   • A) It does not require any write confirmation from replicas.
   • B) It only waits for a single replica to confirm receipt of the log, rather than all replicas.
   • C) It writes to the database cache but bypasses the local WAL.
   • D) It only replicates schemas, not tablespace records.

   Answer: B - Semi-synchronous replication blocks only until at least one replica has acknowledged the write log, balancing latency and safety.

10. What is the Log Sequence Number (LSN) used for in database replication?
    • A) Encrypting network sockets
    • B) Tracking and ordering individual changes in the WAL to coordinate replica catch-up
    • C) Routing queries in a load balancer
    • D) Evicting pages in the Buffer Pool

    Answer: B - The LSN is a monotonically increasing counter representing the byte offset in the log files. Replicas use the LSN to request updates starting exactly from their last saved state.

26. Further Reading

• Designing Data-Intensive Applications (Chapter 5: Replication) by Martin Kleppmann.
• Dynamo: Amazon's Highly Available Key-value Store - The seminal paper on leaderless replication.
• Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases.

27. Next Lesson Preview

In the next module, we will explore Database Sharding. While replication scales reads by copying the same data across multiple nodes, sharding scales writes and storage capacity by partitioning your dataset across entirely separate databases. We will learn how to choose sharding keys, handle cross-shard joins, and execute dynamic re-sharding.