In this chapter
We'll meet DynamoDB Global Tables, real multi-region architecture, managed failure handling, TTL, Streams, and a direct roundup of the anti-patterns this whole Act was quietly built to avoid.
The Problem in Real Life
GreenMart's Singapore customers have been reading and writing to a table physically sitting in a data center on another continent this whole time — every request crossing an ocean, twice, before a page even finishes loading. Sarah is done treating "everywhere" as one region pretending to serve the whole world.
She wants the table itself in Singapore, in the US, and in Europe — all genuinely the same table, not three separate ones GreenMart has to keep in sync by hand.
I don't want three tables that happen to agree. I want one table that's actually everywhere.
Sarah
One Region, Everyone's Latency vs. The Same Table, Everywhere
Global Tables — one table, many regions
The same logical table replicated automatically across regions, each able to read and write locally.
Failure handling is largely AWS's problem now
A failed node, partition, or even region is absorbed by the managed service, not detected and fixed by GreenMart at 3 a.m.
TTL and Streams come free
Automatic (if not instant) expiry, and a real change log every insert/update/delete flows through — no extra infrastructure to build.
The anti-patterns are last chapters' lessons, inverted
Defaulting to Scan, modeling entities before questions, a hot-traffic partition key, normalizing instead of denormalizing.
Global Tables & Multi-Region
Three real, separate questions again, the same pattern this Act keeps returning to. Can the table genuinely live in more than one place at once? What happens when something actually goes wrong? And what real, operational features come free with a managed database that GreenMart never had to build itself?
- On going global — can the table actually live in more than one place? A Global Table is DynamoDB's real, built-in answer: the same table, automatically replicated across multiple AWS regions, with each region able to read and write locally instead of crossing an ocean for every request. This is multi-region architecture made concrete — not three tables GreenMart keeps in sync by hand, but one logical table with copies that propagate changes between regions on their own.
- On staying available — what actually happens when something fails? This is where DynamoDB's managed nature from the very first chapter of this Act pays off directly: failure handling — a failed node, a failed partition, even a failed region with Global Tables in place — is largely AWS's problem to absorb, not GreenMart's to detect and respond to at 3 a.m. the way the Act's own opening incident once was.
- On real, operational features that come free. TTL works the same way it did for Redis — an item can carry an expiry timestamp, and DynamoDB removes it automatically, though the actual deletion is a background sweep, not instant (real expired items can briefly linger, typically well under 48 hours, before they're actually removed — worth knowing, not a bug if it's noticed). DynamoDB Streams is this product's own version of a change log — every insert, update, and delete, in order, available for other systems to react to — the same idea as MongoDB's change streams and Redis's Pub/Sub, DynamoDB's own name for it.
A few real DynamoDB anti-patterns, worth naming directly since this whole Act was really building toward avoiding them: reaching for Scan as the default instead of designing real access patterns around Query from the start; modeling entities first and figuring out queries later, the relational instinct this Act opened by rejecting; choosing a partition key that concentrates traffic instead of spreading it, inviting exactly the hot-partition problem the last chapter covered; and normalizing data the way a relational schema would, instead of denormalizing it deliberately the way single-table design actually depends on. Every one of these is a real, common mistake precisely because each individual choice looks reasonable in isolation — they only reveal themselves as mistakes once real traffic and real scale show up.
Key Takeaway
A Global Table isn't three tables kept in sync by hand — it's DynamoDB's own real mechanism for one logical table that genuinely lives in multiple regions, with failure handling as the direct payoff of everything being managed from the start.
Why This Matters
This closes the loop the very first chapter of this Act opened with: GreenMart stopped wanting to run its own database cluster, and Global Tables — replication, failover, and multi-region reach, all handled without GreenMart operating any of it directly — is the fullest version of what "managed" actually buys.
GreenMart's data can now genuinely live everywhere its customers do, without Sarah operating a single server to make that true. The checkpoint ahead asks Sarah — or you — to design GreenMart's actual order-tracking table from scratch, with every one of this Act's lessons made on purpose.