A replica that fell behind because of one long transaction

Replication lag of eleven minutes on a replica with no load, caused by a single transaction on the primary that took eleven minutes.

why: the replica applies transactions in order, and a
transaction is applied as a unit. a 4-million-row UPDATE
committed on the primary is a 4-million-row UPDATE the
replica must apply before anything after it.

what the lag graph looked like:
  09:00  0s
  09:04  0s
  09:05  rises linearly to 11m
  09:16  drops to 0s instantly

the sawtooth is the signature. it is not a slow replica.

The instant drop is the diagnostic: a genuinely overloaded replica recovers gradually, and a replica waiting on one enormous transaction recovers the moment it finishes. Parallel replication helps only when the transactions are independent, which one big write is not. The fix is on the writing side, which is the batching pattern, and the alert should be on the shape rather than the value.