Database Replication

Build the mental model

A single database instance can only serve so many read queries before its CPU, memory, or disk I/O saturates — buying a bigger machine (vertical scaling) has a ceiling and a steep cost curve. Leader-follower (primary-replica) replication solves this by designating one node as the leader, which accepts all writes, and streaming every change from the leader to one or more follower nodes, which stay synchronized copies. Read traffic can then be spread across the leader and all followers, multiplying read capacity roughly with the number of replicas, while writes still funnel through a single leader, keeping write consistency simple to reason about. The catch is replication lag: streaming changes to followers takes nonzero time, so a follower can briefly serve stale data just after a write lands on the leader — a classic symptom is a user submitting a form, then reloading and not seeing their own change because the read was routed to a lagging replica ('read-your-own-writes' problem). Applications that can't tolerate this must route certain reads back to the leader.

Connect it to a real scenario

As the Tutorial Platform grows, browsing courses and lessons generates far more read traffic than writes (enrolling, submitting a quiz answer), so it adds read replicas: the leader handles writes, and lesson-page reads get load-balanced across several followers, multiplying read capacity without touching write logic. But right after a learner submits a quiz answer, redirecting them to a 'results' page that reads from a lagging replica could momentarily show the old, unanswered state — the platform routes that specific read back to the leader (or waits for replica catch-up) to guarantee the learner immediately sees their own submission.

Leader-follower replication routes all writes through a single leader that streams changes to followers.
Spreading read traffic across leader and followers scales read capacity horizontally.
Replication lag means followers can briefly serve stale data, causing read-your-own-writes problems.

Try the working example

text

                 WRITES
                   |
                   v
            +--------------+
            |   LEADER     |
            +--------------+
              /    |    \
     replicate  replicate  replicate (lag: ~50-200ms)
            /       |        \
           v        v         v
     +---------+ +---------+ +---------+
     |Follower1| |Follower2| |Follower3|
     +---------+ +---------+ +---------+

          READ TRAFFIC (spread across all 4 nodes)
     Leader <-- reads --> F1 <-- reads --> F2 <-- reads --> F3

  Just after a write lands on Leader, F1/F2/F3 may briefly
  return the OLD value until replication catches up ("lag").

You should see

Spreading reads across up to 4 nodes multiplies read capacity, but replication lag means followers can show stale data immediately after a write.

5-minute try-it

Suppose an instructor on the Tutorial Platform edits lesson content, hits save, and immediately reloads the page without seeing their edit. Propose two possible strategies to fix this.

One important caution

Assuming reads are 'scaled' without accounting for the fact that reading from a follower right after a write can return stale data.

Accidentally routing writes to a follower (which should be read-only) due to misconfiguration, corrupting data consistency.

Wikipedia — Replication (computing) — System Design