Beyond simply returning older rows, what user-visible anomalies appear when an application spreads its reads over a pool of asynchronous replicas, and how do you prevent them?

## Why a pool is worse than a single replica A single replica is simply behind by some amount. A pool of replicas is worse: each one applies the primary's change stream at its own pace, so at any instant they occupy different points in the primary's history. Load-balancing reads across them means consecutive requests from the same user can be answered from different moments in the past, in any order. ## Anomaly 1: reads that go backwards Monotonic reads is the property that a session never sees the data move backwards in time. Round-robin routing breaks it: the first request is served by a replica that is 20 ms behind and shows the item; the refresh is served by one that is 3 s behind and the item is missing. Users read this as the system lost my data, and support cannot reproduce it because their request lands elsewhere. Fix: make replica selection sticky. Choose the replica by a hash of the session or user id rather than round robin, so a given user keeps talking to the same copy of the past. If that replica is ejected for lag, the session moves forward in time (to a fresher node), which is harmless; the damage comes from moving backwards. ## Anomaly 2: an effect without its cause Causal anomalies appear when two pieces of related state are read from different places, or when a message travels faster than replication. Typical shapes: a worker receives a queue message referring to row 42, reads a replica, and finds no row 42, because the message overtook the change stream. Or service A writes an order and calls service B, which reads a replica and cannot see the order. Or a UI reads a comment whose parent post is not yet visible, producing a dangling reference even though the primary is perfectly consistent. Fix: carry the write's replication position (LSN or GTID) in the message or the request, and have the reader wait for or verify that position before reading; or read those specific paths from the primary; or make the message carry the payload instead of a pointer to a row. ## Anomaly 3: read skew across a single page A page that runs several queries can have them land on different replicas: the header count is computed from one snapshot, the list from another, and they disagree. Even on one replica, two separate statements see two different apply points, because the replica keeps applying between them. Fix: run the queries that must agree inside a single read-only transaction on one connection, which pins them to one snapshot; or fetch the numbers in one query; or accept the mismatch explicitly for cosmetic counters. ## Anomaly 4: mixing primary and replica in one flow When part of a request reads the primary and part reads a replica, you can observe a newer value and an older value simultaneously (for example a total from the primary against line items from a replica). Keep a logical unit of work on one node. ## Lag fencing All of the above get dramatically worse in the tail. A practical guard is to measure each replica's lag and remove any replica beyond a threshold from the read pool, sending its traffic to the primary or to healthier replicas. Two cautions: measure applied lag, not merely received bytes, since a replica can have the data but not yet have made it visible; and make ejection hysteretic so a replica does not flap in and out. ## Where the boundary is These are operational anomalies of one deployment shape (one writable primary, several read-only copies). The broader question of which consistency model a distributed system offers, and how to route reads at architecture level, belongs to system design; here the answer is concrete: sticky selection, unit-of-work pinning, position tokens, and lag fencing. ## How to present it Do not answer merely the data is a bit old. Name the three concrete shapes (backwards in time, effect without cause, halves of a page disagreeing), tie each to a routing decision that caused it, and give the specific counter-measure for each.