Three availability zones with a Kafka quorum spanning them, so a zone loss costs capacity and not data
Warm standby rather than active-active: active-active would need conflict resolution on notification state for a 30-minute recovery target that a warm standby already meets
The DR region runs at 30 percent and scales on promotion, which trades recovery speed for about 70 percent of a second region's cost
Recovery objectives
RPO 0 in-region for an acknowledged event: replication factor 3, min.insync.replicas 2, acks=all
RPO 5 minutes cross-region, bounded by MirrorMaker lag
RTO 30 minutes, dominated by DNS propagation and standby scale-out, not by data movement
PostgreSQL point-in-time recovery to 7 days, tested monthly
Risks
Provider credentials must be present in the DR region before an incident; Vault performance replication covers this and is the single most likely thing to be missed in a real failover
MirrorMaker offset translation means replayed consumer positions after failover are approximate; the recovery runbook replays from the archive by time range instead
