The Peak-Hour Lag
The health check is green, and the replica is falling behind anyway.
Quiet hour. Replica lag is a fraction of a second.
Where this shows up
Why the read replica gets it wrong
Every replica falls behind at the peak; that’s how replication behaves under heavy writes. More replicas give you more read capacity, and each one comes with its own lag.
By the time the decision ran, its context was outdated. We call that a context gap.
Add read capacity without adding copies.
Tacnode keeps the counts your checks read current at peak, and every service reads the same ones. When you need more read capacity you add nodegroups over the same storage, rather than another copy that can fall behind.
If an engineer asks how
Read capacity scales out with nodegroups over shared storage. Velocity counts are computed on demand against current data, or kept as views refreshed on a schedule you set.
Questions to put to your team
- What does replica lag look like in your busiest minute of the day?
- Which checks read from a replica?
- How would you find out a check undercounted?
Is your velocity check telling this lie?
Bring it to a demo, and we’ll trace what it reads and how old that data is by the time it runs.
Book a demo →