Balvinder Singh — BS monogramBalvinder SinghPaymentsAIArchitecture
← Writing
Platform Architecture1 min read

Cross-region failover for payment platforms

Cross-region failover for a payment platform has different constraints from a general web application. What the design has to preserve.

Cross-region failover for a general web application is a well-understood pattern: replicate state, route around outages, reconcile on recovery. For a payment platform, the same pattern needs to preserve properties that a general web application doesn't have to worry about.

Written October 2024 from a DR design engagement.

What must survive a failover

  • In-flight transaction identity. A transaction that was authorizing when the primary region failed must be recoverable, either by continuation in the secondary or by explicit cancellation.
  • Batch integrity. A batch in mid-construction must not be lost, duplicated, or partially submitted.
  • Idempotency-key state. The receiver on the secondary must recognize keys from before the failover to prevent double-processing on retry.
  • Reconciliation state. The last reconciliation checkpoint must transfer, so the recovery reconciliation doesn't reprocess history.

What actually goes wrong

  • Asynchronous replication lag. A transaction committed to the primary but not yet replicated to the secondary is invisible on failover.
  • Split-brain risk. If both regions think they're primary for a moment, the same transaction gets processed twice.
  • Time skew. Clocks between regions drift; a failover event that treats timestamps naively produces confusing ordering.
  • Retention windows. Idempotency keys retained for 24 hours in-region may not survive a cross-region failover cleanly.

Design decisions worth making early

  • Synchronous replication for authorization-critical state, asynchronous for reporting. The trade-off is latency for durability; for auth, the durability wins.
  • Explicit region tagging on every event. So reconciliation after failover can distinguish "processed in primary" from "processed in secondary".
  • A rehearsed failover drill. Not a document; an actual drill, run at least twice a year with real traffic diverted.

Cross-region failover for payments is expensive to build and expensive not to have. The middle case — thinking you have it and finding out you don't — is the worst.