DynamoDB Global Tables: Multi-Region Active-Active Replication With Low Latency

Most databases have a single authoritative region. Data is written there and read replicas in other regions serve read traffic. If you need to write from Paris, the write travels to Virginia, commits, and the acknowledgment travels back. That round trip takes hundreds of milliseconds. For many applications that latency is acceptable. For global consumer applications — a social platform, a gaming leaderboard, a real-time collaboration tool — it is not.

DynamoDB Global Tables solves this with active-active replication: any replica in any region can accept writes. Users in Tokyo write to the Tokyo replica; users in Frankfurt write to the Frankfurt replica. Both replicas stay synchronized with sub-second lag.

How Global Tables Work

Global Tables is built on DynamoDB Streams. When you add a region to a Global Table, AWS creates a DynamoDB Streams-based replication channel between all participating regions. Every write to any replica generates a stream record, which is picked up by a system-managed replication process and written to all other replicas.

  DynamoDB Global Tables Architecture
  =====================================

  us-east-1             eu-west-1             ap-northeast-1
  ─────────────         ─────────────         ─────────────
  DynamoDB              DynamoDB              DynamoDB
  Table                 Table                 Table
  (replica)    ◄──────► (replica)   ◄──────► (replica)
       │                    │                    │
       │                    │                    │
  Users in US          Users in EU          Users in Asia
  write locally         write locally         write locally
  (~2ms latency)        (~2ms latency)        (~2ms latency)

  Replication lag: typically < 1 second between regions
  All replicas are writable (active-active)

Each region is an independent table that can serve all operations — reads and writes — even if other regions are temporarily unreachable. This is the key difference from a read replica: a read replica becomes unavailable for writes when the primary is gone. A Global Table replica keeps accepting writes independently.

Conflict Resolution

When the same item is written in two regions within a very short time window, both writes propagate to all regions. This creates a conflict: which version wins? Global Tables uses last-writer-wins based on the write timestamp at the regional level.

  Conflict Scenario
  =================

  t=0ms:    User in us-east-1 writes item A, sets value = "Boston"
  t=50ms:   User in eu-west-1 writes item A, sets value = "Dublin"
  t=300ms:  us-east-1 replication arrives in eu-west-1
  t=350ms:  eu-west-1 replication arrives in us-east-1

  Both regions see a conflict. DynamoDB compares timestamps:
  - If "Boston" write was at t=0ms and "Dublin" at t=50ms:
    "Dublin" wins (higher timestamp) in all regions

  Result: all regions converge to "Dublin"

  Design implication: if two users can legitimately write the
  same item simultaneously, your application must handle this
  via application-level conflict resolution, not relying on
  database semantics.

This conflict model is fine for most use cases — user preferences, session state, profile updates. It is not appropriate for banking ledgers or any scenario where concurrent writes to the same item carry business logic that cannot be overwritten.

When to Use Global Tables

Low-latency writes for global users: a user in Singapore should not wait 250ms for a write to complete because the database is in Ireland. With Global Tables, Singapore writes to ap-southeast-1 and the operation completes in milliseconds.

Regional disaster recovery with write capability: standard cross-region read replicas cannot accept writes. If your primary region fails, you must manually promote a replica — and decide what to do with writes that arrived in-flight. Global Tables eliminates this problem because all regions are already writable. No promotion step required.

Compliance with data residency requirements: some regulations require specific customer data to be processed in a specific geography. Global Tables lets you run the same application globally while respecting data residency by routing certain users to specific regional replicas.

Provisioned vs On-Demand Capacity with Global Tables

Each replica has its own capacity configuration. If you provision 1,000 WCUs in us-east-1, that capacity is only for writes originating in us-east-1 — replication writes from other regions consume additional capacity that AWS handles automatically (replicated writes are included in the pricing model, but the capacity reservation applies to local writes).

On-demand capacity is simpler with Global Tables because you do not need to estimate write traffic per region — you pay per request and the table scales automatically.

Adding a Region to an Existing Table

Global Tables v2 (2019 and later) allows converting an existing DynamoDB table to a Global Table by adding replicas:

# Add eu-west-1 replica to an existing table in us-east-1
aws dynamodb update-table \
  --table-name UserProfiles \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]' \
  --region us-east-1

AWS backfills the new replica with existing table data before enabling live replication. This process runs in the background without downtime to the primary table.

Global Tables vs Cross-Region Read Replicas (Aurora/RDS)

  Global Tables vs Aurora Global Database
  ========================================

  Feature                    | DynamoDB Global Tables   | Aurora Global Database
  ---------------------------|--------------------------|----------------------
  Write from any region      | Yes (active-active)      | No (active-passive)
  Conflict resolution        | Last-writer-wins         | No conflicts (one writer)
  Failover to secondary      | No failover needed       | Manual or automated (~1 min)
  Replication lag            | < 1 second typical       | < 1 second typical
  Data model                 | NoSQL (key-value/doc)    | Relational SQL
  Regions                    | Up to 20                 | Up to 5 secondaries

Real-World Use Case: Global Gaming Leaderboard

A mobile game has players in North America, Europe, and Southeast Asia. The leaderboard updates in real time as players complete levels. Requirements:

• Score submissions must feel instant — players should not notice a delay after finishing a level
• Leaderboards must be consistent within a region — players in the same region should see the same rankings

Solution: DynamoDB Global Table with replicas in us-east-1, eu-west-1, and ap-southeast-1. Score writes go to the nearest region. Replication propagates scores globally within about a second. Cross-region conflicts are rare (two players submitting the exact same score at the exact same millisecond) and last-writer-wins is acceptable for a leaderboard.

Key Interview Points

• Active-active means all replicas accept writes — this is the key difference from standard read replicas
• Conflict resolution is automatic and last-writer-wins — design your data model to avoid business-critical conflicts
• Streams must be enabled on the base table — Global Tables requires DynamoDB Streams and manages its own stream consumers
• Replication is asynchronous — a write committed in us-east-1 may not yet be visible in eu-west-1 if you read immediately after writing; design for eventual consistency across regions
• IAM permissions are per-region — a role with DynamoDB access in us-east-1 does not automatically have access to the eu-west-1 replica; manage permissions in each region
• Global Table pricing includes replication write units — writes cost more than they would on a single-region table because the replication traffic is metered