Write to any Region mode (no primary)
The write to any Region write mode is fully active-active and doesn’t impose restrictions on where a write operation may occur. Any Region can accept a write request at any time. This is the simplest mode; however, it can be used only with some types of applications. It’s suitable when all write operations are idempotent. Idempotent means that they are safely repeatable so that concurrent or repeated write operations across Regions are not in conflict—for example, when a user updates their contact data. It also works well for an append-only dataset where all write operations are unique inserts under a deterministic primary key, which is a special case of being idempotent. Lastly, this mode is suitable where the risk of conflicting write operations is acceptable.

The write to any Region mode is the most straightforward architecture to implement. Routing is easier because any Region can be the write target at any time. Failover is easier, because any recent write operations can be replayed any number of times to any secondary Region. Where possible, you should design for this write mode.
For example, several video streaming services use global tables for tracking bookmarks,
reviews, watch status flags, and so on. These deployments can use the write to any
Region mode as long as they ensure that every write operation is idempotent. This
will be the case if every update—for example, setting a new latest time code, assigning
a new review, or setting a new watch status—assigns the user’s new state directly, and
the next correct value for an item doesn’t depend on its current value. If, by chance, the
user’s write requests are routed to different Regions, the last write operation will persist
and the global state will settle according to the last assignment. Read operations in this
mode will eventually become consistent, delayed by the latest ReplicationLatency
value.
In another example, a financial services firm uses global tables as part of a system to
maintain a running tally of debit card purchases for each customer, to calculate that
customer’s cash-back rewards. New transactions stream in from around the world and go to
multiple Regions. This firm was able to use the write to any Region mode
with a careful redesign. The initial design sketch maintained a single
RunningBalance
item per customer. Customer actions updated the balance with an
ADD
expression, which is not idempotent (because the new correct value depends
on the current value), and the balance got out of sync if there were two write operations to
the same balance at around the same time in different Regions. The redesign uses event
streaming, which works like a ledger with an append-only workflow. Each customer action
appends a new item to the item collection maintained for that customer. (An item
collection is the set of items that share a primary key but have different sort
keys.) Each write operation is an idempotent insert that uses the customer ID as the partition
key and the transaction ID as the sort key. This design makes the calculation of the balance
harder because it requires a Query
to pull the items followed by some client-side
math, but it makes all write operations idempotent and achieves significant simplifications in
routing and failover. (This is discussed in more detail later in this guide.)
A third example involves a company that provides online ad placement services. This company decided that a low risk of data loss would be acceptable to achieve the design simplifications of the write to any Region mode. When they serve ads, they have just a few milliseconds to retrieve enough metadata to determine which ad to show, and then to record the ad impression so they don’t repeat the same ad soon. They use global tables to get both low-latency read operations for end users across the world and low-latency write operations. They record all ad impressions for a user within a single item, which is represented as a growing list. They use one item instead of appending to an item collection, so they can remove older ad impressions as part of each write operation without paying for a delete operation. This write operation is not idempotent; if the same end user sees ads served out of multiple Regions at approximately the same time, there’s a chance that one write operation for an ad impression could overwrite another. The risk is that a user might see an ad repeated once in a while. They decided that this is acceptable.