An Indian UPI payments app runs its transaction platform in a single cloud region (Mumbai) with a warm standby in Hyderabad; payment data must stay in India. A three-hour regional networking event last quarter stopped all payments for 47 minutes while the team failed over by hand, and two thousand transactions needed manual reconciliation afterwards. Peak load is 30,000 payments per second, and the two Indian regions are roughly 15 to 20 ms apart in round-trip time.
The interviewer asks“The CTO wants 'active-active, zero downtime, zero data loss' for the payment platform. Tell me what you'd actually build, why true multi-writer active-active is hard for money, and which option you'd recommend.”
True multi-writer active-active for money means two places can decide the fate of the same transaction at once, and during a partition you must choose between refusing writes and accepting conflicting ones — for payments that's not a choice, you refuse. So I'd make the system active-active at the user level, not the row level: users are sharded into cells, each cell has exactly one writer region at a time, synchronous replication inside the region across AZs, and a small quorum-replicated intent journal across three sites so no submitted transaction ID is ever lost. Failover moves cell ownership with fencing tokens, so a stale owner physically cannot submit payments. Both regions serve live traffic, the blast radius of a failure is one cell, and only the state that must be strictly consistent pays the consensus latency.
A free account unlocks the rest of it, and saves your progress across every track.