The one thing to understand first
Disaster recovery is the discipline of answering two numbers before disaster strikes: RPO — how much data you can afford to lose — and RTO — how long you can afford to be down. Every cross-region PostgreSQL design is a negotiation between those two targets and the unavoidable physics of a wide-area network. The earlier Pathway 04 lessons gave you the building blocks (streaming replication, slots, archiving, failover, pg_rewind); this lesson is the strategy layer that assembles them into a DR posture you can actually measure and rehearse.
This extends Pathway 04 by tying its replication and recovery primitives to the RPO/RTO targets and the WAN constraints that drive real disaster-recovery architecture.
The mechanism: why the WAN forces async
Synchronous replication makes the primary wait for a remote standby to confirm WAL before a commit returns — synchronous_commit = on/remote_write/remote_apply with the standby in synchronous_standby_names. Across a metro distance that’s tolerable; across a continent it adds the full network round-trip to every commit, which usually wrecks write throughput. So cross-region DR is almost always asynchronous: the primary ships WAL to the far region without waiting, accepting that at the instant of a disaster some WAL may not have crossed the wire yet. That unshipped WAL is your data loss — which means your RPO is just the replication lag at the moment of failure.