Global Tables
Global Tables
Global tables replicate one DynamoDB table across regions for an active-active setup: every region is a full replica that accepts reads and writes, and changes propagate through DynamoDB Streams with conflict resolution by last-writer-wins. Replication is asynchronous and typically completes in under a second, so each region serves strongly consistent reads of its own replica while cross-region reads remain eventually consistent.
Design for conflict, not against it: concurrent edits to the same item in two regions silently converge to one winner. When a global counter or inventory level must not lose increments, route writes for that partition key to a single home region or model the change as an event rather than a mutable value.
Streams, TTL, and DAX
Streams, TTL, and DAX
Streams capture item changes as ordered records (NEW_AND_OLD_IMAGES) with a 24-hour retention window; trigger Lambda from them for projections, replication, or audit trails. Delivery is at-least-once, so consumers must handle replays and duplicates.
TTL marks items with an epoch attribute; DynamoDB deletes them asynchronously, typically within 48 hours. Use it for session expiry and cost control — never as an access-control mechanism.
DAX is a write-through, in-memory read cache in front of the table delivering microsecond reads. It invalidates on writes and does not serve strongly consistent reads; the client and cluster must run inside a VPC.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
Classic failure modes: a single hot partition key (sequential timestamps, one "misc" PK) saturating one shard while the table sits at 5% capacity — fix the key design or add randomization; a stream consumer that double-processes during a redeploy, which dedupe keys prevent; TTL deletion lag surprising anyone expecting immediate removal; and Stream retention expiring (24 hours) after the consumer is down too long.
Global tables add subtlety: last-writer-wins means lost updates. DAX adds cost and VPC complexity — ElastiCache may fit better if you need consistent reads or already run Redis code.
Interview: draw the write path (item → shard → stream → consumer), then state each guarantee: consistency, ordering per key, delivery, and lag.
Quiz
1. How does DynamoDB resolve concurrent writes in different regions of a global table?
2. When is a TTL-expired item actually deleted?
3. What is a true limitation of DAX?
Flashcards
Question
Global table conflict rule
Click to reveal answer
Answer
Last writer wins across regions; replication via DynamoDB Streams, typically sub-second.
Question
Stream retention
Click to reveal answer
Answer
24 hours; consumers must be resilient and idempotent (at-least-once delivery).
Question
TTL semantics
Click to reveal answer
Answer
Epoch attribute → async delete, typically within 48 hours; never for access control.
Question
DAX
Click to reveal answer
Answer
Write-through VPC cache for microsecond eventually-consistent reads; invalidates on writes.
Question
Hot partition symptom
Click to reveal answer
Answer
One PK saturates a shard while table-wide capacity looks idle — redesign the key.
Revision Notes
Key Takeaways
- 1. Streams are the backbone: replication, triggers, and CQRS all flow through them
- 2. TTL lags; DAX skips consistent reads; global tables lose update races by design
- 3. Key design determines whether your table scales or melts down
Interview Tips
- • State guarantees explicitly: per-key ordering, at-least-once delivery, 24h retention, last-writer-wins
- • Bring a key-design story: how you avoided a hot partition in a high-write table
Cheat Sheet
Global tables: async, last-writer-wins, sub-second. Streams: 24h retention, at-least-once, per-key order. TTL: async delete ≤~48h, not ACL. DAX: write-through, VPC, no consistent reads.