Cross-region replication (Global Tables) in DynamoDB - Time & Space Complexity
When using DynamoDB Global Tables, data is copied across regions automatically.
We want to understand how the time to replicate data grows as more data changes.
Analyze the time complexity of replicating write operations across regions.
// Pseudocode for replication event
for each write in region A {
send change to region B;
apply change in region B;
}
This code shows how each write in one region is sent and applied to another region.
Look for repeated actions that affect time.
- Primary operation: Sending and applying each write change to other regions.
- How many times: Once per write operation made in the source region.
As the number of writes increases, the replication work grows too.
| Input Size (writes) | Approx. Operations (replications) |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The replication work grows directly with the number of writes.
Time Complexity: O(n)
This means the time to replicate grows in a straight line as more writes happen.
[X] Wrong: "Replication time stays the same no matter how many writes happen."
[OK] Correct: Each write must be sent and applied, so more writes mean more replication work.
Understanding how replication time grows helps you design systems that stay fast as they grow.
"What if replication was done in batches instead of one write at a time? How would the time complexity change?"
Practice
Solution
Step 1: Understand Global Tables concept
Global Tables replicate data automatically across multiple AWS regions to keep them in sync.Step 2: Identify the main purpose
This replication helps applications stay fast and available worldwide by having data close to users.Final Answer:
To keep data copied and synchronized across multiple AWS regions -> Option AQuick Check:
Global Tables = cross-region data sync [OK]
- Confusing backups with replication
- Thinking Global Tables increase table size
- Assuming encryption is the main feature
Solution
Step 1: Identify the correct command for creating Global Tables
The command to create a Global Table iscreate-global-tablewith replication group specifying regions.Step 2: Check options
aws dynamodb create-global-table --global-table-name MyTable --replication-group RegionName=us-east-1 usescreate-global-tablewith replication group, which is correct. Others are for creating normal tables, updating, or deleting.Final Answer:
aws dynamodb create-global-table --global-table-name MyTable --replication-group RegionName=us-east-1 -> Option CQuick Check:
Create Global Table = create-global-table command [OK]
- Using create-table instead of create-global-table
- Confusing update or delete commands
- Missing replication group parameter
Solution
Step 1: Understand replication behavior of Global Tables
Global Tables replicate writes made in one region to all other regions automatically and quickly.Step 2: Apply to the scenario
Writing an item in us-east-1 will replicate it to eu-west-1, making it available there.Final Answer:
The item is immediately available in eu-west-1 after replication -> Option AQuick Check:
Write in one region = replicate to others [OK]
- Thinking writes stay local only
- Assuming writes fail across regions
- Confusing replication direction
Solution
Step 1: Check schema requirements for Global Tables
All replicas in Global Tables must have the same primary key schema to replicate correctly.Step 2: Identify cause of error
If the new region's table has a different primary key schema, adding it will fail.Final Answer:
The new region's table has a different primary key schema -> Option BQuick Check:
Matching primary keys required for Global Tables [OK]
- Assuming encryption causes add-region errors
- Believing Global Tables limit regions to two
- Confusing update-table with update-global-table commands
Solution
Step 1: Consider latency and availability
Replicas in all user regions reduce latency by serving data locally.Step 2: Understand consistency trade-offs
Strongly consistent reads across regions are not supported; eventual consistency is used to balance latency and consistency.Step 3: Evaluate options
Create replicas in Asia, Europe, and America regions with eventual consistency reads creates replicas in all needed regions with eventual consistency, which is best for performance and availability.Final Answer:
Create replicas in Asia, Europe, and America regions with eventual consistency reads -> Option DQuick Check:
Global Tables + eventual consistency = low latency worldwide [OK]
- Expecting strong consistency across regions
- Using single region causing high latency
- Skipping regions to save cost but hurting users
Ready to prove it?
Pass the test and this pattern moves unknown
