Global Tables

Your database runs in us-east-1 (Virginia). A user in Tokyo makes a request. The request travels from Tokyo to Virginia (about 150ms one way), the database processes it (5ms), and the response travels back (another 150ms). Total: 305ms just for the network round trip.

For a read-heavy application, a product catalog, a configuration service, a content platform, this latency is unacceptable. Users in Asia, Europe, and South America all experience sluggish performance because every read crosses the ocean.

Read replicas in each region help, but they introduce replication lag. A user in Tokyo writes a review, then immediately refreshes the page, and the review isn't there because the Tokyo replica hasn't received the write from Virginia yet.

Global tables take a different approach. Instead of one primary and multiple read replicas, every region has a full, writable copy of the table. Writes in any region are automatically propagated to all other regions. The table is truly global, not a primary with followers, but a multi-master setup where every region is equal.

DynamoDB Global Tables, Azure Cosmos DB, Google Spanner, and CockroachDB all support this pattern. The mechanics and trade-offs differ, but the goal is the same: low-latency reads and writes for users worldwide.

The fundamental idea: replicate the entire table to multiple regions, and accept writes in any region.

DynamoDB Global Tables:

• Replicate a DynamoDB table across chosen AWS regions
• Writes in any region are asynchronously propagated (typically < 1 second)
• Reads are local. Tokyo users read from the Tokyo replica
• Conflict resolution: last-writer-wins based on timestamp
• No application code changes needed beyond selecting the local endpoint

Cosmos DB with Multi-Region Writes:

• Replicate containers across any combination of Azure regions
• Writes can be sent to any region
• Conflict resolution: configurable (last-writer-wins, custom merge procedures, or custom stored procedures)
• Five consistency levels: strong, bounded staleness, session, consistent prefix, eventual

Spanner:

• Global strong consistency using TrueTime
• Writes go through Paxos consensus across replicas
• Reads can be strongly consistent (wait for consensus) or stale (read from local replica)
• Higher write latency than DynamoDB (consensus overhead) but stronger guarantees

The key architectural question: how are write conflicts handled?

When a user in Tokyo and a user in London update the same record at the same millisecond, what happens? The answer depends on the system: