Read replicas relieve pressure on a primary, but they also introduce a second system property the product team now has to live with: uncertainty about freshness.
Replica reads are a correctness budget
The right question is not whether lag exists. The right question is what kind of lag the user can tolerate before the product starts violating its own meaning.
Product semantics come before topology
When engineers say a replica is eventually consistent, they often stop too early. The product team needs a more concrete statement: which screens can be stale, how stale, and what user actions become risky when lag rises.
Diagram
Primary write, replica read timeline
Replica lag is not static
Lag changes with throughput, schema work, maintenance events, and downstream contention. Treating it as a constant turns a design shortcut into a reliability trap.
Premium boundary
Continue with the full Read Replica Staleness article.
The preview stops at the point where tradeoff detail, failure chains, and implementation judgment begin to compound. Paid access unlocks the full essay and the rest of the premium library.