Read replicas
Copies that share the reads.
Picture a food-delivery app at dinner time. Customers browse restaurants and menus all evening: about 5,000 reads per second. Orders and status changes are far rarer, maybe 1,000 writes per second. One database server handles all of it until it nears its ceiling, and then every page load and every order slows down together. Browsing is hurting ordering, even though browsing is the less important job.
A read replica fixes the imbalance. It is a second database server that receives every change the primary makes and keeps its own copy of the data. Your app sends writes to the primary and sends many reads to the replicas. Because most apps read far more than they write, this is often the cheapest big step up in capacity.
How a change reaches a replica
Step 1 of 4
The primary records the change
Before it answers the app, the primary appends the change to an ordered log (a write-ahead log or binary log, depending on the database). This log is the source of truth for what changed and in what order.
Replicas also help availability. If one replica dies, the others carry on and you replace it. If the primary dies, a replica can be promoted to take its place (the topic of a later lesson). But a replica is not a backup: if someone runs a bad delete on the primary, the delete is faithfully copied to every replica within moments.
Your turn
Your ticket shop reads 12,000 times per second and writes 600 times per second. One database copy handles at most 6,000 operations per second. How many copies (primary plus replicas) do you need if reads split evenly and every copy applies all writes? Show the arithmetic.
Stuck? Each copy handles its share of reads plus all writes.
What to remember
A replica copies the primary's change log and serves reads.
Replicas scale reads but not writes; every copy replays every write.
A replica is not a backup: bad deletes replicate too.
Expect small delays between primary and replica.