Why architecture matters here
The architecture matters because latency and availability are both regional problems, and a single-region database solves neither for a global audience. Every kilometer between a user and their data is speed-of-light latency that no amount of caching fully hides for writes, and a database confined to one region is a single point of failure for the entire planet's worth of users. Global tables attack both at once: by placing a full, writable replica in each region where you have users, reads and writes complete against nearby infrastructure, and the loss of any one region leaves the others fully operational. This is a qualitatively different posture from a read-replica-in-another-region setup, where the far region can read but must still cross the ocean to write and cannot survive the primary's loss without a promotion dance.
The second forcing function is that active-active multi-master is the only model that gives local write latency everywhere, and it is exactly the model that creates conflicts. A single-writer design (one region owns writes, others forward to it) keeps data trivially consistent but reimposes the cross-region latency on every write and reintroduces a single point of failure for writes. Choosing multi-master means choosing to accept writes locally in every region, which means two regions can independently accept conflicting writes to the same item during the propagation window. There is no free lunch here: the very property that makes global tables fast and available — accept writes anywhere, replicate later — is the property that makes conflicts possible. The architecture's job is not to eliminate conflicts (impossible without giving up the benefit) but to resolve them deterministically and to shape the data model so conflicts rarely matter.
The third reason is that last-writer-wins is a specific, opinionated resolution with real consequences that you must design for. When two writes to the same item race, DynamoDB keeps the one with the larger timestamp and discards the other entirely — not field-by-field, but the whole item version. If two regions each update a different attribute of the same item concurrently, one region's update is lost, not merged. This makes global tables excellent for data where items are naturally owned by one region or where occasional lost updates are tolerable (user session state, last-seen timestamps, per-user preferences written from the user's home region) and dangerous for data where concurrent multi-region edits to the same item must all survive (a shared counter, a collaboratively-edited document). Recognizing which kind of data you have is the central design decision.
The fourth architectural payoff is operational: global tables are fully managed, so the replication, conflict resolution, and region-addition are AWS's problem, not yours. You do not run replication daemons, manage replication slots, or write conflict-resolution code; you enable replication to a new region and DynamoDB backfills and then keeps it in sync. This is a large reduction in operational surface compared to self-managed cross-region replication, and it is a major reason teams reach for global tables even when a single-region setup would technically suffice — the multi-region reliability comes almost for free operationally, provided the data model fits the last-writer-wins contract. The cost is loss of control: you cannot choose a different conflict-resolution strategy, so the data model has to bend to the platform's, not the other way around.
A fifth consideration is that eventual consistency changes what the application can promise its users, and that has to be reasoned about explicitly rather than discovered in production. Because a write in one region takes a moment to appear in another, a user whose request is routed to a different region between two operations can read their own write as absent — write a profile change in one region, read it back through another a few milliseconds later, and see the old value. For many workloads this read-your-writes anomaly is harmless or easily avoided by pinning a user's session to one region; for others it is a correctness bug that must be handled by routing, by reading with strong consistency within the writing region, or by designing the flow so cross-region read-after-write does not happen. The architecture does not remove the anomaly — it is inherent to asynchronous multi-master replication — so the application must decide, per flow, whether the anomaly is acceptable and route accordingly.
The architecture: every piece explained
Top row and left: the replicas and how a change is captured. Each region — us-east, eu-west, ap-south — holds a full replica of the table, and the local application reads and writes its own replica at regional latency; there is no designated master. When the app in us-east writes an item, that change is captured by Streams, DynamoDB's change-data-capture log, which records every insert, update, and delete in order. This stream is the source of truth for replication: everything that must propagate to the other regions flows through it, so replication is exactly the act of applying one region's change stream to every other region's replica.
Right and middle: shipping and applying changes. The managed replicator reads each region's stream and ships the changes across regions, where they are applied to the other replicas. This is asynchronous — the originating write completed locally the moment it was durable in its own region, and the cross-region propagation happens afterward, typically within a second. When a change arrives at a replica that has concurrently changed the same item, the LWW resolver compares timestamps and keeps the newer version, discarding the older, so all replicas deterministically converge on the same winner regardless of the order in which they receive the conflicting writes. That determinism — every replica picks the same winner by timestamp — is what guarantees the copies eventually agree.
Bottom row: the properties you operate against. Replication lag is the window between a write completing in one region and appearing in another; it is usually sub-second but is real and variable, and it is the window during which conflicts and stale reads live. Conflict on the same key names the specific hazard: concurrent writes to one item in two regions, resolved by last-writer-wins with one write lost. The ops strip lists the health signals — cross-region replication latency, the rate at which conflicts occur, the read/write capacity provisioned in each region (which must independently handle that region's load plus the replicated write traffic from all others), and failover readiness so that when a region is lost, traffic can shift to the survivors cleanly.
End-to-end flow
Follow a user preference update in a three-region global table. A user in Berlin toggles a setting; their request routes to the eu-west application, which writes the item to the eu-west replica. The write is durable in eu-west within a few milliseconds and the app returns success — the user waited only for the local region. DynamoDB Streams captures the change, the replicator picks it up, and within a few hundred milliseconds the updated item is applied to the us-east and ap-south replicas. A moment later, the same user's read from anywhere in the world returns the new value. The user experienced local-latency write and the data became globally consistent without them ever waiting on a cross-region hop.
Now inject a conflict. The same user is briefly connected through two regions — an old session in eu-west and a new one that got routed to us-east — and both write the same preference item within the same fifty-millisecond window, before either write has propagated. Each region durably accepts its own write locally and returns success to its caller. Then the streams cross: eu-west's write arrives at us-east and us-east's arrives at eu-west. At each replica the LWW resolver compares the two versions' timestamps and keeps the one written later. Because the comparison is deterministic and symmetric, both regions independently converge on the same winner, and a moment later all three replicas hold identical data. The earlier write is gone — not merged, discarded — which is fine for a last-toggle-wins preference and would be a bug for a value that needed both updates to survive.
Consider the stale-read anomaly explicitly. Immediately after the Berlin write completes in eu-west, suppose a different device for the same user issues a read that happens to route to ap-south, whose replica has not yet received the propagated change. That read returns the old value — the user 'lost' their update for the sub-second replication window. If the application pins each user's session to a home region, this never happens, because the read and write hit the same replica. If it does not, the flow must tolerate the brief staleness or read with strong consistency inside the writing region. The architecture makes the anomaly possible; the application's routing and consistency choices decide whether users ever see it.
Finally, a region fails. The eu-west region has an outage; the eu-west replica is unreachable. Because every other replica is a full, writable copy, the application simply routes European users to the next-nearest healthy region — say us-east — and they continue reading and writing, now at slightly higher latency but with no data loss beyond any writes that were in-flight in eu-west's stream and had not yet propagated when it went dark. When eu-west recovers, DynamoDB resumes replication, catches the replica up from where it left off, resolves any conflicts by timestamp, and the region rejoins the active set. No promotion, no manual failover of a primary — the always-writable-everywhere design means failover is a routing change, not a database operation, which is the whole payoff of the active-active model.