Multi-region design: name the write and recovery contract

Active-active compute is not the same as active-active durable data. Define traffic routing, write ownership, replication mode, conflict policy, quorum, capacity, dependencies and recovery gates separately.

RPO and consistency

For DynamoDB multi-Region eventual consistency (MREC), local writes replicate asynchronously. The recovery point is approximately the unreplicated window; AWS describes RPO/RTO in seconds and exposes ReplicationLatency. Do not label this zero RPO. Concurrent writes also need idempotency and deterministic conflict behavior.

Multi-Region strong consistency (MRSC) can support zero RPO for its supported topology, but a write waits for remote coordination. Latency rises and a partition can make writes unavailable. Never combine “synchronous zero RPO” and “RPO of a few seconds” as if they were one mode.

Failover and backup

Failover checks the surviving region's capacity, service dependencies, replication lag, data integrity and write mode before routing. Reconcile client operations whose result was ambiguous. Record:

• achieved RPO: accepted data lost or unavailable after recovery;
• achieved RTO: time from declared disruption to verified service recovery.

Replication can faithfully copy a destructive write, so keep isolated, versioned backups and test restoration plus replay.

Scenarios

Sources

• DynamoDB global-table design
• DynamoDB replication latency
• Dynamo paper
• AWS disaster recovery planning