Write to your Region mode (mixed primary)
The write to your Region write mode assigns different data subsets to different home Regions and allows write operations to an item only through its home Region. This mode is active-passive but assigns the active Region based on the item. Every Region is primary for its own non-overlapping dataset, and write operations must be guarded to ensure proper locality.
This mode is similar to write to one Region except that it enables lower-latency write operations, because the data associated with each user can be placed in closer network proximity to that user. It also spreads the surrounding infrastructure more evenly between Regions and requires less work to build out infrastructure during a failover scenario, because all Regions have a portion of their infrastructure already active.
You can determine the home Region for items in several ways:
-
Intrinsic: Some aspect of the data, such as a special attribute or a value embedded within its partition key, makes its home Region clear. This technique is described in the blog post Use Region pinning to set a home Region for items in an Amazon DynamoDB global table
. -
Negotiated: The home Region of each dataset is negotiated in some external manner, such as with a separate global service that maintains assignments. The assignment might have a finite duration after which it’s subject to re-negotiation.
-
Table-oriented: Instead of creating a single replicating global table, you create the same number of global tables as replicating Regions. Each table’s name indicates its home Region. In standard operations, all data is written to the home Region while other Regions keep a read-only copy. During a failover, another Region temporarily adopts write duties for that table.
For example, imagine that you’re working for a gaming company. You need low-latency read and write operations for all gamers around the world. You assign each gamer to the Region that’s closest to them. That Region takes all their read and write operations, ensuring strong read-after-write consistency. However, when a gamer travels or if their home Region suffers an outage, a complete copy of their data is available in alternative Regions, and the gamer can be assigned to a different home Region.
As another example, imagine that you’re working at a video conferencing company. Each conference call’s metadata is assigned to a particular Region. Callers can use the Region that’s closest to them for lowest latency. If there’s a Region outage, using global tables allows quick recovery because the system can move the processing of the call to a different Region where a replicated copy of the data already exists.
