Scaling Reads
A single primary can become a bottleneck for read heavy apps. Read replicas are copies of the primary that serve read queries, spreading load. The primary still handles all writes and ships its changes to replicas.
The Staleness Problem
- Replication is asynchronous, so a replica lags the primary by some delay.
- A user who writes then immediately reads a replica may see old data.
- This breaks the expectation of read your own writes.
Common Fixes
- Route a user's reads to the primary for a short time after they write.
- Track a version or timestamp and wait until the replica catches up.
- Send latency tolerant queries to replicas and critical ones to the primary.
Key idea
Read replicas scale read traffic by copying the primary, but asynchronous lag can serve stale data, so route writes followed by reads to the primary or wait for catch up.