Read Replicas & Read-Your-Writes

Foundations

In the first lesson, one primary served every read and write. Now, what if reads outgrow it, or it fails, and copies of the data must serve reads too?

Replication streams the primary's log of committed writes to read replicas. With asynchronous replication, the primary acknowledges a write before the replicas apply it, so a replica can lag behind by a moment: fast writes, slightly stale reads. Read-your-writes fixes the worst case: after a user writes, route that user's reads to the primary for a few seconds, so they always see their own change.

Take a primary at log position 41 and a replica at 39. A record committed at 40 is missing from the replica for a moment, so a stranger reading there sees the older state, which is acceptable. The user who wrote it is routed to the primary for a few seconds and sees it immediately.

• Databases

  Queues and partitions sit around a primary database. That lesson covers the key and the index.

  Open lesson

Case Scenario

To see how replicas trade freshness for capacity, consider a URL shortener like bit.ly: the primary takes every create, redirects are served from a cache, and a cache miss may read a replica. The creator of a new short link must be able to open it immediately, while a stranger may see it up to a second later.

A create can succeed moments before another machine serves the first redirect, and a machine can fail while that create is still moving through the system. Treating every reader alike either slows all reads or surprises the person who just created the link. The creator of x7Kp must open it immediately; a stranger may observe it up to about one second later.