Replication and consistency for active-active regions?

WHAT THIS TESTS Whether you grasp that active-active across regions means accepting fundamental trade-offs between consistency, latency, and durability, and can choose deliberately per data type rather than hand-waving.

A GOOD ANSWER COVERS Start by classifying data by its recovery point objective, the tolerable data loss. For money-movement or auth state you may want synchronous or quorum-based replication so a committed write survives a region loss, accepting that every write now pays cross-region round-trip latency and that a partition can block writes. For less critical data use asynchronous replication, which keeps writes fast and regions available but means a failover can lose the last few seconds of un-replicated writes. With writes in multiple regions you must handle conflicts: use single-writer ownership per key or shard, last-writer-wins with caveats, application-level merge, or CRDTs for commutative data. Frame the reasoning with CAP, during a partition you choose consistency or availability, and PACELC, which adds that even without a partition you trade latency against consistency. State your RPO and RTO targets and design backward from them.

COMMON WRONG ANSWERS Claiming you can have strong consistency, low latency, and zero data loss everywhere, which the theorems forbid. Ignoring write-write conflicts in active-active. Treating last-writer-wins as conflict-free when it silently drops data. Picking synchronous replication globally without acknowledging the latency and availability cost.

LIKELY FOLLOW-UPS How do CRDTs avoid conflicts. What RPO does async replication imply. How do you detect and resolve a split brain. How does quorum sizing affect availability.

ONE CONCRETE EXAMPLE For a wallet service you put balances behind a per-account home region with synchronous quorum writes, so a failover loses no committed transaction but distant users see slightly higher write latency. User preferences, which tolerate loss, replicate asynchronously and resolve concurrent edits with last-writer-wins. During a region outage the wallet stays consistent and may briefly reject some writes, while preferences stay fully available, an intentional split aligned to each data class's RPO.