LEARN. PRACTICE. GROW.Start with the invariant and read path
Before choosing a database, state what must never happen: a repeated reservation, authorization using stale state, or two Regions accepting the same exclusivity claim. In DynamoDB, tables and LSIs support strong reads, but GSIs do not. A GSI query may not yet reflect a just-confirmed write. The design needs a path meeting the requirement; adding ConsistentRead to an unsupported index is insufficient. A strong read also does not lock the item against subsequent changes. In the exercise, two workers read balance 80 and both want to reserve 60. Reading the same current value does not arbitrate the conflict. The relevant condition belongs in the write operation or suitable transaction; the application must handle rejection and reassess the outcome.
Transaction boundary and request retries
TransactWriteItems groups atomic changes in one account and Region; BatchWriteItem can partially succeed. Do not use two actions against the same item in one transaction: a condition on the updated item can accompany the Update itself. A request token supports idempotency for ten minutes after initial completion. A business replay the next day needs a strategy surviving that window. In the exercise, the processing record and reservation are separate items in one Region. The proposal creates them atomically with suitable conditions, retaining identity and result for the defined replay horizon. Calling an external processor does not make that call part of the transaction. Identify that boundary and plan external-result confirmation or reconciliation. Keep timeout examples both before and after commit to avoid blind retries.
Eventual replication does not create global exclusivity
Current global tables distinguish MREC from MRSC. In MREC, replication is asynchronous, same-item conflicts converge through last writer wins, and conditions evaluate the local version. Requests in different Regions can both pass an absence condition before the remote write arrives. A local strong read does not force arrival of a change made elsewhere. Nor should a multi-item regional transaction be presented as an atomic unit in replicas: items can appear at different times. For global exclusivity, reconsider the design with a write authority or a mechanism that actually meets the invariant, including failover of that authority. In a rehearsal, record both accepted outcomes and the converged state; a single final state does not erase external effects produced by both acceptances.
Choose MRSC without promising unsupported features
MRSC provides global strong reads at replicas when strong reads are requested and evaluates conditions against the latest version. Inspected documentation requires three Regions, using three replicas or two plus a witness; the witness does not serve application reads or writes. Regions must belong to a supported set. Also check features: current documentation does not support transactions, TTL, or LSIs in MRSC. It is not a transparent replacement for every MREC design. An existing global table’s consistency mode cannot be changed. A project requiring a change must plan a new design, data transition, and validation instead of promising a simple toggle. Acceptance evidence includes observed latency, failure behavior, invariant enforcement, and compatibility with operations used by the application.
Original MREC thought experiment; not AWS deployment code
Initial: reservation K absent in replica A and replica B
A: conditional create K accepted before replication
B: conditional create K accepted before replication
Later: replicas converge on one item version
Question: did convergence undo either external effect?
Answer: no; application arbitration/reconciliation is requiredTwo MREC Regions accept the same reservation before replication. Later convergence does not establish that only one external-processor effect occurred.
Common pitfalls
Treating a strong read as a lock; using a GSI for guaranteed freshness; extending transactions to external services; assuming atomicity across MREC replicas; promising TTL or transactions in MRSC.
Related topics: Queues, retries, and recovery
Every guarantee has a scope; demonstrate the invariant at the scope the business requires.
Reference: DynamoDB read consistency · SAP-C02