Write to any Region mode (no primary) - AWS Prescriptive Guidance

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.


        No primary write mode

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.