cloudparts

Writes in several regions at once

Accepting writes close to users in more than one region, and staying up when a whole region goes down.

What it asks of a system

There are two ways to let several regions take writes, and they trade latency for consistency. Asynchronous multi-active replication, as in DynamoDB global tables (in their default mode) or Cassandra across datacenters, commits a write in the local region and ships it to the others afterwards. Writes are fast everywhere, but two regions can change the same item at once, and the system has to pick a winner, usually the last writer by timestamp. A transaction committed in one region may also show up partly applied in another for a moment. Synchronous designs, such as Spanner or CockroachDB, commit a write only once a quorum of replicas, spread over regions, has it. Nothing is lost if a region fails, but each write waits for at least one round trip between regions.

The synchronous systems soften that cost by giving each row or table a home region: rows homed near the user are written with local latency, and only data that every region reads, such as reference tables, pays for a global write. So the useful questions are where a given row’s writes are decided, what a client in another region sees right after a write, how conflicts are resolved, and what still works while one region is cut off.

To judge a system, read what its docs say about conflict resolution, the replication lag it reports, whether transactions stay atomic across regions, and its recovery point when a region fails (zero or a few seconds of writes).

Good at it · 7

Compare side by side

Wide-column stores

Sources

Why each technology is listed comes from the sources on its own page.