Your order database has a synchronous standby in a second zone and an asynchronous copy in a second region — what differs when you promote each?

## Two copies making two different promises A replica is defined by **when the write is acknowledged relative to when the copy has it**. - **Synchronous**: the primary does not confirm the write to the caller until the second copy has durably accepted it. The cost is paid on every single write, forever. The benefit is paid once, at promotion: there is nothing to lose. - **Asynchronous**: the primary confirms immediately and ships the change afterwards. The cost is paid once, at promotion — everything not yet shipped is gone. The benefit is paid on every write: no waiting. Distance is what forces the choice. Zones inside one region are separated for failure isolation but sited close enough that a round trip is small, which is precisely what makes synchronous replication practical there. A second region is far away by design — that is the point of it — so the round trip would be added to every commit, and virtually nobody accepts that. Hence the shape almost every stack ends up with: **synchronous inside the region, asynchronous across regions**. | | Synchronous standby, second zone | Asynchronous copy, second region | |---|---|---| | Cost per write | a small latency addition on every commit | none | | Data lost at promotion | none of the acknowledged writes | whatever the lag held | | Protects against | losing one zone | losing the whole region | | Typical promotion time | short, often automated | longer, usually declared by a person | | Failure while healthy | a sick standby can slow or stall writes | lag grows quietly and nobody notices | ## The lag is not a constant The most useful thing to say about asynchronous replication is that the lag is a **variable you must measure, not a property you can assume**. It grows when the write rate rises, when a bulk job runs, when the link between regions is congested, and when the receiving side is busy applying what it already has. That means the lag is usually largest exactly when you are most likely to need the copy — during peak trading, or during the incident that is about to become a regional one. A plan that quotes a comfortable normal lag and never alarms on it is a plan built on the best case. ## What promotion does to everything else Promotion is not only a data event. Four things happen around it: 1. **Every open connection breaks.** Connection pools reconnect, and whatever was in flight fails. Callers need retries, and the operations behind them need to be safe to repeat, because some of those failed requests did commit before the connection dropped. 2. **Clients have to find the new writable copy.** Whether that is a name that repoints, a proxy that moves, or configuration that changes, that step has its own delay and its own cached copies sitting in callers. 3. **The old primary must be fenced.** If it comes back and still believes it is writable while the promoted copy is also taking writes, you have two divergent truths and a painful reconciliation. Stopping the old one accepting writes is part of promoting, not a follow-up task. 4. **Failing back is a second migration.** The promoted copy has accepted writes the old one never saw, so returning is a planned cutover with its own lag and its own window, not an undo. ## A replica is not a backup Both of these copies replicate faithfully — which means they replicate the mistake too. A wrong bulk update or a delete of the wrong rows is applied to the standby and to the far copy as diligently as any other change, usually within seconds. Replication protects against **losing a failure domain**; a backup with a retention window protects against **something being wrong in the data**. They are different controls for different risks, and a design that has only one of them is missing half its coverage. ## How to answer this out loud State the definition in terms of acknowledgement, not in terms of speed — 'the caller waits' against 'the caller does not wait'. Then give each promotion its consequence: no data loss and a latency tax, against no latency tax and a data-loss window equal to the lag. Then add the parts most candidates skip: broken connections, repointing clients, fencing the old primary, and the fact that neither copy is a backup. If you are asked which you would choose, the answer is usually both, for different failures, and the interesting question is what lag you are willing to sign for.