DynamoDB Global Tables: Multi-Region Replication Explained
Multi-region is a product decision, not a checkbox. Amman travel lead Omar Haddad and Osaka engineer Kenji Watanabe said: We turned on Global Tables for inventory — two regions sold the same seat. Catalog reads love replicas; contended inventory needs sticky writes. Hot partitions still hurt in every region: hot partitions.
What you'll learn in this chapter
- Explain Global Tables simply
- Choose sticky writes vs multi-writer
- Describe replicas and conflicts (LWW)
- Industry map
- Lab mindset + cleanup
1. Everyday example: shared family calendar
Two phones edit the same event — last save wins (LWW). Dinner reservation for one table cannot be double-booked casually. Meera keeps clinic slot writes in one region; website content replicas everywhere.
2. Vertical steps
3. Why do we need this?
Why do we need this?
Users far away need low-latency reads. DR goals may need a warm region. But every multi-writer item risks conflicts and double-sells.
4. What is it?
What is it?
Global Tables replicate a DynamoDB table across Regions. Conflicts typically resolve last-writer-wins per item. You still design keys; replicas copy the pain of hot partitions too.
5. How to do it (step by step)
How to do it (step by step)
- List which entities are multi-writer safe (catalog) vs sticky (inventory).
- Pick regions for users and DR.
- Add replicas; wait ACTIVE.
- Route writes: sticky for contended stock/seats.
- Monitor ReplicationLatency and conflicts.
- Document failover: DNS/app region shift.
6. Commands with output and meaning
# Inspect replicas (API varies by setup)
aws dynamodb describe-table --table-name ShopApp \
--query 'Table.{Name:TableName,Replicas:Replicas,Status:TableStatus}'
# Meaning: see Regions; Status ACTIVE before traffic.
# Add replicas only on disposable lab tables — each region bills writes.describe-table shows replica list. Add replicas only on labs first — each region bills writes.
7. Industry stories
- Travel (Omar): catalog GT; seat inventory sticky home region.
- Media (Priya): read-heavy article metadata multi-region.
- Fintech (Elena): ledgers single-region; reporting async export.
- Gaming (Carlos): player profiles GT; wallet single-region.
- Retail (Aisha): store catalog GT; warehouse stock sticky.
- SaaS (Omar): tenant config GT; billing single-region.
8. Lab
How to do it (step by step)
- On paper: split CartLite entities into GT-safe vs sticky.
- If account allows: tiny lab table + one replica; describe; delete replicas then table.
- Else: write failover checklist only — still valid lab.
Cleanup (stop billing)
- Delete lab resources you created.
- Confirm with describe that names are gone.
9. Ops checklist before you ship
- Confirm TTL attribute name and units (epoch seconds).
- Decide soft-delete vs hard-delete vs archive-to-S3.
- Enable PITR on any table you cannot rebuild from source.
- Document RPO/RTO and who runs restore drills.
- If multi-region: pick write stickiness and conflict rules.
- If DAX: prove cache-miss path and warm-up plan.
- Tag Owner + Expiry on every lab resource.
- Budget alert in the account before load tests.
10. Copy-paste DynamoDB CLI starters (batch 2)
export AWS_DEFAULT_REGION=ap-south-1
# TTL status
aws dynamodb describe-time-to-live --table-name ShopApp
# PITR / continuous backups
aws dynamodb describe-continuous-backups --table-name ShopApp
# On-demand backup
aws dynamodb create-backup --table-name ShopApp --backup-name lab-shop-$(date +%Y%m%d)
# List backups
aws dynamodb list-backups --table-name ShopApp
# Global table description (v2)
aws dynamodb describe-table --table-name ShopApp --query 'Table.Replicas'11. More industry stories
- Retail (Aisha Khan, Dubai): TTL clears abandoned carts; soft-delete keeps 30-day undo.
- Bank (Lucas Meyer, Berlin): PITR on ledger table; restore drill every quarter.
- Travel (Omar Haddad, Amman): Global Tables for catalog reads; inventory writes sticky.
- Gaming (Carlos Rivera, Mexico City): DAX for hot profile Gets; never cache money ledgers.
- Social (Priya Nair, Kochi): adjacency edges for follows; sparse GSI for unread inbox.
- IoT (Mei Lin, Shenzhen): device#day PK + TTL 14 days; rollups to S3.
12. Glossary (batch 2)
| Term | Meaning |
|---|---|
| TTL | Time to Live — attribute with epoch seconds; DynamoDB deletes later |
| Soft delete | Flag deleted=true; item remains until TTL/archive |
| PITR | Point-in-time recovery — continuous backups window |
| Global Table | Multi-region replicated DynamoDB table |
| LWW | Last-writer-wins conflict resolution on replicas |
| DAX | DynamoDB Accelerator — in-memory cache cluster |
| Adjacency list | Edge items modeling relationships in one table |
| Fan-out | Write once; push copies to many feeds/inboxes |
13. Practice: explain out loud
- 60s: TTL vs soft-delete vs S3 archive.
- 60s: PITR vs on-demand backup.
- 60s: when Global Tables help and hurt.
- 60s: DAX consistency trade-off.
- 60s: CartLite checkout keys in one breath.
- 60s: follow edge vs feed item.
- Record once; cut filler; record again.
14. Safe lab hygiene
- Use ap-south-1 labs with a budget alert.
- Prefix lab tables with lab- and your initials.
- Delete replicas, DAX clusters, and backups you created for labs.
- Never enable Global Tables on production without a write plan.
- Tag every resource Owner + Expiry.
- Export/import labs can create large S3 bills — delete prefixes.
15. How this set links other chapters
- Data modeling — keys we reuse in projects.
- Transactions — checkout and seat patterns.
- Streams + Lambda — fan-out and CDC.
- CRUD survey — short TTL note we deepen.
- What Is DynamoDB? — intro.
16. Delete / archive decision pad
| Need | Prefer | Why |
|---|---|---|
| Undo 7-30 days | Soft-delete flag | User restore |
| Hard expiry, no read | TTL attribute | Auto delete later |
| Compliance keep cold | Export/archive to S3 | Cheap long store |
| Mistake recovery | PITR / backup | Table-level restore |
17. Ten oral drill questions
- What units does DynamoDB TTL use?
- Does TTL delete instantly?
- PITR window typical length?
- Global Tables conflict default?
- When sticky writes matter?
- DAX vs API Gateway cache?
- Cart PK for a shopper?
- Order lines under which PK?
- Follow edge SK example?
- Unread inbox sparse GSI idea?
18. RPO / RTO mini workshop
- Write the worst data loss you can accept (RPO) in minutes.
- Write how long restore may take (RTO) before business pain.
- Map: on-demand backup vs PITR vs multi-region replica.
- Schedule a restore drill on a lab table this month.
- Name the person who runs the drill.
19. Cost watch list (batch 2)
- PITR storage and on-demand backup storage.
- Global Tables: replicated WCUs in every region.
- DAX node hours even at idle.
- Export to S3 + S3 storage + Athena later.
- Streams + Lambda still bill during TTL deletes.
20. Project Definition of Done
- Access patterns written and peer-reviewed.
- Sample items drawn for happy path + one failure.
- Lab table created, exercised, deleted (or tagged Expiry).
- At least one conditional write or transaction exercised.
- Cleanup commands pasted in your notes.
- One interview answer recorded out loud.
21. Cross-links inside this batch
- TTL hygiene → Backup/PITR for “oops” recovery.
- Global Tables → sticky writes from capacity/hot lessons.
- DAX → only after Query shapes are correct.
- P1 CartLite reuses modeling + transactions.
- P2 Social reuses adjacency + Streams ideas.
22. Quick self-check (yes/no)
- I can explain TTL delay vs instant DeleteItem.
- I know when soft-delete beats hard delete.
- I can start PITR and say what restore costs in time.
- I can name one reason NOT to use Global Tables.
- I know DAX does not fix a bad partition key.
- I can sketch CartLite USER# and ORD# keys.
- I can sketch a follow edge item.
- I delete lab replicas/DAX/backups the same day.
23. Common errors and fixes
Each row is a real mistake students and juniors hit. Read the fix before you panic.
| Error / symptom | Fix |
|---|---|
| GT for double-sell stock | Sticky writes. |
| Ignore LWW | Design conflicts. |
| Hot PK + GT | Fix keys first. |
| No latency monitor | Watch ReplicationLatency. |
| Prod first try | Lab first. |
| Forget regional cost | Budget each region. |
| DNS not planned | Failover runbook. |
| Txn across regions casually | Know limits. |
| Assume strong global consistency | Replicated/eventual across regions. |
24. Troubleshooting checklist
- Replica Creating: wait/IAM.
- Conflict surprises: review LWW + sticky.
- Throttle in one region: hot key local.
- High bill: replicated WCUs.
- App reads stale: expect replication lag.
25. FAQ
Q. Should I always use a single table?
Often yes for related access patterns; not a religion. Separate tables are fine for unrelated domains or different capacity/security needs.
Q. Do I still need RDS?
Yes for heavy joins, multi-row SQL reports, and strong relational constraints. See the intro DynamoDB vs RDS chapter.
Q. Is Scan evil?
Scan is a tool for rare admin jobs and small tables. Design so hot paths use Query/GetItem.
Q. Where are Put/Get command details?
In the CRUD survey, CLI and SDK chapters — this deep set links them instead of copying.
Q. Always need GT?
No — single region often enough.
Q. LWW safe for seats?
Usually no — sticky or carefully designed.
Q. Fixes hot partitions?
No — replicas copy the heat.
Q. Link modeling?
Yes — keys still matter.
26. Interview Q&A
Q. (B) Global Table?
Multi-region replicated DynamoDB table.
Q. (B) Default conflict?
Last-writer-wins per item.
Q. (M) Sticky writes?
Send contended writes to one region.
Q. (M) Catalog vs inventory?
Catalog multi-writer OK; inventory careful.
Q. (S/MNC) DR with GT?
Warm replica + app/DNS failover plan.
Q. (MNC) Cost surprise?
Writes replicated — pay in each region.
27. Tips in English, Marathi and Hindi
Ravindra Bagale's Tip (EN)
Replicate reads freely; treat contended writes like cash.
Ravindra Bagale's Tip (MR)
Reads free-ish; contended writes = cash.
Tip (HI)
Read replicate ठीक; contested write को cash समझो।
Try at home
- Classify 5 entities: GT-safe vs sticky.
- Write a 5-line failover checklist.
- Re-read hot partitions chapter one page.
In short
- GT = multi-region replicas.
- LWW conflicts — design sticky where needed.
- Hot keys hurt every region.
- Lab first; watch replicated cost.
Revision, interview and comparison cards
Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.
More cards: Ravi Sir's Cards.
Practice Tasks
London Legal LLP is a law business in London. Oliver Hughes looks after its IT and cloud work. They count money in GBP and run their AWS resources in the eu-west-2 Region. In the tasks below you do real jobs for them using what this lesson teaches. All names, account IDs, IP addresses and numbers are made up for practice.
0 / 16
Easy GT = multi-region replicas — 1
Why: Def.
What to do: Enter 1 if Global Tables replicate across Regions.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Easy Conflicts often LWW — 1
Why: Conflict.
What to do: Enter 1 if conflicts often resolve last-writer-wins.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Easy Sticky writes for seats — 1
Why: Inventory.
What to do: Enter 1 if contended seats/stock often use sticky writes.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Easy Hot keys still hurt — 1
Why: Keys.
What to do: Enter 1 if hot partitions can hurt in every region.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Easy Describe table replicas
Why: CLI.
What to do: Describe table ShopApp
- Read the task and decide which AWS service it is about.
- Write aws, then the service name, then the operation (the action word).
- Add each needed flag (--name) followed by its value from the task.
- Flags can be in any order. Click Check answer.
Easy Entity split YAML
Why: Classify.
What to do: YAML: catalog: multi-writer, inventory: sticky.
- Start from the top-level keys the task names.
- Indent child keys with 2 spaces (no tabs).
- Fill in each property with the value from the task.
- Click Check answer. Key order does not matter.
Easy Double-sell risk with blind multi-writer — 1
Why: Risk.
What to do: Enter 1 if blind multi-writer seats risk double-sell.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Medium Catalog often OK multi-writer — 1
Why: Split.
What to do: Enter 1 if catalogs are often safer multi-writer than inventory.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Medium Writes bill per region — 1
Why: Bill.
What to do: Enter 1 if replicated writes bill in each region.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Medium Watch ReplicationLatency — 1
Why: Metric.
What to do: Enter 1 if ReplicationLatency is a key GT metric.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Medium Failover needs DNS/app plan — 1
Why: Runbook.
What to do: Enter 1 if failover needs an app/DNS cutover plan.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Medium Failover checklist YAML
Why: List.
What to do: YAML list checks with dns and health.
- Start from the top-level keys the task names.
- Indent child keys with 2 spaces (no tabs).
- Fill in each property with the value from the task.
- Click Check answer. Key order does not matter.
Hard Try GT on labs first — 1
Why: Safety.
What to do: Enter 1 if you should try replicas on labs before prod.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Hard Do not assume strong global — 1
Why: Model.
What to do: Enter 1 if you should not assume strong global consistency.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Hard GT not always required — 1
Why: Choice.
What to do: Enter 1 if single-region is often enough.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.
Hard Fix keys before GT — 1
Why: Order.
What to do: Enter 1 if you fix hot keys before adding replicas.
- Write down the numbers the task gives you.
- Work it out step by step on paper.
- Type only the final answer in the box.
- Click Check answer.