When nines fight microseconds

State the collision plainly. Five-nines durability (3.2): no output before a quorum of zone-separated journals acknowledges. Zone separation means kilometers; kilometers mean hundreds of microseconds at lightspeed-in-fiber, round trip, twice over. The colo rung's entire budget is 50 µs. You cannot have zone-synchronous durability and colo-grade latency on the same order. This is not an engineering shortfall to be optimized away later — it is geometry. What remains is choosing, per venue, which promise bends:

flowchart TB
    Q{"Where must event N be durable before its fill is published?"}
    Q --> O1["ACROSS ZONES — kilometers apart. Cost: +0.5–2 ms. Survives: zone loss with RPO 0. The 5 ms rung — Part 3's choice, unchanged (3.2)"]
    Q --> O2["ACROSS A METRO CAMPUS — zones chosen hundreds of meters apart. Cost: +100–400 µs. Survives: building loss with RPO 0, metro disaster asynchronously (3.3). The 500 µs rung"]
    Q --> O3["WITHIN ONE BUILDING — replicas in separate fire cells on separate power. Cost: +10–20 µs. Survives: machine and room loss with RPO 0. Building loss: async ship + halt-reconcile-auction (3.3). The 50 µs rung"]
    

The colo option looks, at first, like abandoning Part 3 — until you apply 3.1's own discipline: availability of what, for whom? A colo-grade venue's participants have racked their servers in that same building (4.6). If the building is destroyed, the market's participants are offline with it; a matching engine surviving alone in another region would preside over silence, then face 3.3's halt-reconcile-auction anyway once everyone re-homed. For that venue, in-building quorum plus an aggressively-shipped async copy (seconds behind, 3.3) is the honest five-nines design — the contract was never "survive anything invisibly," it was "never lose a fill that any surviving participant saw, and reopen fairly from provable state." Both of which in-building quorum plus the 3.3 runbook deliver. Meanwhile a global retail venue makes the opposite call for equally good reasons: its users are everywhere, perceive nothing below ~50 ms of WAN, and are served best by option 1's geographic indifference. Same course, two correct exchanges.

Close the part by noticing how much of the latency ladder was already built by the availability ladder — the deep pattern of the whole course. The single-writer deterministic core (1.3, 1.7): chosen for correctness and replay, turns out to be the lock-free, cache-warm hot path (4.4). Post-trade decoupling (1.10): chosen to protect availability, removed four subsystems from the latency budget (4.3). Bounded queues and shedding (2.7): chosen to survive overload, are what keep the tail honest under load (4.5). Differential monitoring (3.5): built to catch gray failure, is the jitter alarm (4.5). And the replay log (1.7) warms the caches before the open (4.5). You did not build an available exchange and then a fast one; you built one machine whose virtues kept compounding — which is what a good architecture is.