Replication lag is the gap in time between a write being applied on the leader and that same write appearing on a follower. It is an unavoidable feature of asynchronous replication, where, as PostgreSQL puts it, the system allows “some delay between the time of a commit and its propagation to the other servers.” During that window the leader and its followers hold different versions of the data.
MongoDB defines the term directly: “Replication lag is a delay between an operation on the primary and the application of that operation from the oplog to the secondary.” It warns that the consequences grow with the gap: “Some small delay period may be acceptable, but significant problems emerge as replication lag grows, including building cache pressure on the primary.” To keep lag bounded, MongoDB applies flow control that throttles the write rate when lag exceeds a configured target.
The visible symptom of lag is reading stale data. If an application writes to the leader and then reads from a lagging follower, it may see an older value, or fail to see its own just-completed write at all. These anomalies are exactly what stronger consistency guarantees address. Read-your-writes consistency, for instance, ensures a user always sees their own updates, typically by routing that user’s reads to the leader or to a follower known to be caught up.
Because lag means followers temporarily disagree with the leader, asynchronous leader-follower systems offer eventual consistency rather than strong consistency: given enough time with no new writes, the followers converge to the leader’s state, but at any single moment they may be behind. Tightening this gap is a trade-off, since the synchronous alternative removes lag only by making writes wait for followers, raising latency and reducing availability.