Primary-Replica Replication (Read Replicas)

Picture a teacher — the 'primary' — writing notes on the whiteboard. Several students — the 'replicas' — copy those notes into their own notebooks. That way everyone can read them without crowding around the board. Only the teacher writes new notes; students just copy. That's replication. One primary database handles all the writes, and streams every change to one or more replica copies. Spreading reads across the replicas lets far more people read at once. But a slow-copying student's notebook might briefly lag behind what's on the board. This is called replication lag.

1. 1Every write goes to exactly one server: the primary. It applies the change, and appends it, in order, to a running log of everything that changed.
2. 2Each replica reads that log and applies the same changes, in the same order, to its own copy of the data.
3. 3Reads get spread across the replicas, instead of all hitting the primary. This way, read traffic doesn't overload the one server that also handles writes. A replica that hasn't caught up yet may return slightly stale — out-of-date — data.

Use this once your app is popular and has far more reads than writes — like a blog, a product catalog, or a news feed. Add several read replicas, so all that read traffic doesn't pile onto the one server that's busy handling writes.

• ⚠Sending a write straight to a replica. Replicas are meant to be read-only copies. Writing to one breaks the whole replication setup.
• ⚠Assuming a replica is always instantly up to date. Reading from a lagging replica right after a write can show you the old value. This is called the 'read-your-own-writes' problem.