Can Your Invariant Survive a DynamoDB Global Table?

A pre-creation operation matrix for admitting or rejecting DynamoDB MREC and MRSC, including item boundaries, regional transactions, index reads and immutable...

Abstract

Before creating a DynamoDB global table, decide which application operations it is allowed to accept. “We need active-active” is not an invariant. “Only one caller may reserve this seat, regardless of the serving Region” is. “A payment must debit one account and credit another atomically” is a different requirement, even if both teams call it strong consistency.

This paper argues for operation-level admission before deployment. Multi-Region eventual consistency (MREC) can be appropriate where independent regional updates and their convergence are acceptable, or where application routing supplies a separately enforced authority. Multi-Region strong consistency (MRSC) can support a cross-Region, latest-item conditional decision, but it does not supply multi-item transactions, strongly consistent global secondary indexes, or a transaction with a payment provider. Several deployment choices are fixed when the table becomes global. A weighted architecture score must not average away a mandatory failure.

The deliverable is a fillable operation matrix, a completed hypothetical assessment and a bounded rehearsal plan. All cases are fictional and NOT EXECUTED. No AWS table, account, application, log or metric was queried or changed. The diagrams describe documented contracts, not measured service behavior. A provisional candidate still needs implementation evidence and an accountable technical review.

1. Define the admissibility question

An invariant is a statement that must remain true across the operations the application accepts. Examples include no duplicate reservation for one seat, conservation of value across ledger entries, and an expiration rule that prevents use after a specified instant. State the scope and the observation point: accepted by the API, recorded in the database, charged by the provider, or visible in a customer listing. These are not interchangeable milestones.

An atomic item boundary is the set of attributes modified together on one DynamoDB item. A condition on that item can protect its transition. It does not automatically protect a second item, a derived index, a cached response or an external effect. A read path identifies the actual API, Region, table or index and consistency option. Calling a path “DynamoDB” leaves the important part unspecified.

We use three verdicts. REJECT means a mandatory requirement contradicts the documented candidate contract. HOLD means evidence or an application rule is missing. CANDIDATE means the known contract does not yet reject the design. It does not mean tested, safe under all failures or approved to deploy. An architecture can have a candidate reservation operation and a rejected payment operation. That is not permission to put both into the same table unchanged.

For broader datastore selection, use the database constraint matrix. For an already selected architecture's recovery contract, use regional recovery consistency contracts. This paper stops before recovery execution and capacity diagnosis.

2. Establish the exact table model before discussing consistency

The scope here is same-account global tables using the current version, 2019.11.21. AWS documents a legacy 2017.11.29 version separately. Record the version, account boundary and proposed consistency mode instead of treating examples from different versions as interchangeable. The same-account reference and current behavior reference are the source of this scope.

AWS also documents multi-account global tables, which do not support MRSC. That is a separate model, not an extension silently admitted by this worksheet. If account separation is mandatory, this paper's MRSC candidate is rejected until the architecture question is reformulated against the applicable product.

The consistency mode cannot be changed after the global table is created. All replicas use the same mode. The UpdateTable API exposes the consistency parameter when creating a new global table; its EVENTUAL default is not a migration procedure for an existing MREC table. Put the explicit intended mode in the reviewed design record. A future desire for stronger behavior is a new data and application migration problem, not a switch promised in the backlog.

Global tables use regional endpoints. AWS's design guidance does not provide a single global endpoint that chooses a writer for the application. Routing, account authority and endpoint configuration must therefore be part of the operation record.

3. MREC conditions protect local decisions, not independent global admission

MREC replicates changes asynchronously and resolves simultaneous changes to the same item using last-writer-wins reconciliation based on internal timestamps. Its conditional writes evaluate against the local replica's item. A strongly consistent read in one Region can see the latest local write without proving that every remote write has arrived. These contracts are explicit in the current behavior reference.

Consider a fictional seat item with version = 0 and reservation = empty in two Regions. Before propagation, each Region can evaluate a condition requiring version zero against its own local copy. Both calls may be accepted. Eventual reconciliation can leave one item value, but it does not withdraw the two confirmations already sent to customers. A converged item is not evidence that the business admitted only one reservation.

This rejects independent multi-Region writers for a strict single-winner reservation under that model. It does not reject MREC for every reservation design. An application can instead send all authoritative decisions for a seat to one Region, prevent another Region from independently admitting that seat, and document how routing and authority are enforced. That alternative changes the requirements: remote readers may lag, and the application needs an explicit authority contract. “Normally routes to one Region” is insufficient if fallback routing can admit independently.

MREC is a plausible candidate where concurrent outcomes are acceptable or explicitly reconciled. An independently updated regional preference or an append-oriented event record may fit a different invariant. The reviewer still needs the actual key model, duplicate handling and acceptable observation semantics. Last-writer-wins should not be relabeled as a general merge that preserves every business update.

4. MRSC changes the item contract, not the whole application contract

MRSC synchronously replicates item changes to at least one other Region before a successful write response. Conditional writes evaluate against the latest version of the item. Strongly consistent reads can return the latest item in any serving replica. Eventually consistent reads can still return stale data. These are the documented contracts, not a license to infer a hidden leader, voting layout or application latency from the topology. See global table behavior.

An ordered reservation example is useful. Request A conditionally changes version zero to version one and receives success. Request B then reaches another serving replica with a condition requiring version zero. Under the MRSC latest-item condition contract, B cannot satisfy that condition against version one. This trace demonstrates the required evaluation scope without inventing a deterministic winner for simultaneous requests.

Actual concurrent modifications can receive ReplicatedWriteConflictException. AWS documents retrying after the conflicting request completes. The application must decide what a retry means: re-read, reevaluate the business precondition, preserve the original operation identity, and report a rejected reservation where appropriate. It must not remove the condition just to make a retry succeed. The exact concurrency exercise remains unexecuted here.

An accepted single-item transition is still only that transition. It does not prove that an email was sent once, a card was charged once, or a second item was modified. Application correctness cannot be imported from the word “strong.” Record the next boundary separately.

*Logical evaluation traces, not an AWS run or physical topology. MREC local acceptance is a possibility before propagation. The MRSC trace is deliberately ordered, not a claim about which concurrent caller wins. Regional endpoints shown are examples within the operation contract; the required deployment topology is checked separately.*

5. A multi-item payment is a different admission problem

Suppose a fictional payment requires a debit item, a credit item and a payment-status item to change atomically. MRSC does not support DynamoDB transaction operations. The requirement therefore rejects an unchanged MRSC design even if every individual conditional write evaluates the latest item. Three correct single-item checks do not create a joint commit.

MREC supports regional transactions, but their atomicity is confined to the Region where the transaction is invoked. Replication to another Region is not an atomic unit, so a remote observation can see part of the transaction. The transaction reference and global-table behavior must be read together. A regional transaction can be a candidate for a regional-authority ledger contract; it is rejected for a requirement that every replica observe the multi-item commit atomically.

The external payment provider adds another boundary. A database transaction does not include the provider's charge. Even a regional ledger transaction needs a documented operation identity, external idempotency contract, acceptance receipt and reconciliation rule. This paper does not supply a payment implementation or claim that an outbox guarantees exactly-once external execution.

A redesign could colocate the complete invariant in one item if its access patterns and item constraints genuinely permit it. That is an option to evaluate, not a universal solution. Another option is a regional transaction authority with explicitly weaker remote observations. A third is a different store or workflow with the required joint-commit contract. Each must name what changes for clients. Reject “split it into separate writes and call it atomic” without a replacement invariant.

6. An index path can invalidate an otherwise suitable base-item design

DynamoDB supports strongly consistent reads on tables and local secondary indexes, but not on global secondary indexes or Streams. MRSC does not support LSIs at all. The read-consistency reference and GSI reference keep these paths separate.

A customer dashboard that queries a GSI for all pending payments is not converted into a latest complete listing by selecting MRSC. A recently created matching item can be missing from the index result. Strongly reading every returned base item can reject stale candidates, but cannot discover a candidate the index did not return. That technique therefore does not establish complete latest membership.

Decide whether the listing is informational or authoritative. If temporary omission is accepted, specify how the user experiences it and what path confirms a critical operation. If the business requires complete latest membership at this exact step, reject this GSI-based path and redesign the access pattern or contract. A cache or materialized projection creates another freshness boundary, not a shortcut around the index rule.

Read-committed isolation also does not lock an item against a subsequent change. A successful strong read followed by an unconditional write is not the same as a conditional state transition. The operation matrix must record the write precondition, not just a reassuring read flag.

7. Deployment eligibility is a mandatory gate

As checked on October 7, 2026, MRSC requires exactly three Regions: either three serving replicas, or two replicas and one witness. The witness is managed by DynamoDB, does not serve application reads or writes, and is not an extra regional table that a client can route to. The current behavior and design guidance list the following supported sets.

A configuration cannot span these sets. A mandatory serving replica in Mumbai ap-south-1 is not eligible for MRSC under this dated inventory. Two serving replicas plus a witness do not satisfy a requirement for three application-serving Regions. Record the role of every Region, including the witness, rather than counting labels on a diagram.

MREC has a different placement contract and can use DynamoDB-supported Regions within the applicable partition. That can make it a placement candidate while it remains an invariant rejection for independent global reservation writers. Placement does not override item correctness. Recheck the current list before implementation; a dated worksheet must not pretend to certify future service availability.

8. TTL and LSI requirements must survive the design choice

MRSC does not support TTL or LSIs. If the existing design requires either, mark MRSC REJECT for that unchanged requirement. Do not quietly remove the feature from the comparison and treat its replacement as free. The exclusion is documented in global-table behavior.

A TTL-based cleanup process also does not establish immediate deletion at the expiration instant. AWS's TTL guide describes asynchronous removal of eligible expired items. An application expiration invariant may need to reject expired data on reads and writes even while the item remains physically present. A retention obligation needs its own verified deletion and copy-handling process.

Replacing an LSI with a GSI changes the consistency and access-path contract. Replacing TTL with an application cleanup worker changes ownership, authorization, backlog handling and deletion evidence. Both may be valid redesign proposals, but remain HOLD until their replacement requirements and tests are documented. Neither is a small toggle that admits the original architecture automatically.

*Admission constraints, not a performance comparison. The MREC column assumes independent regional admission; enforcing regional authority is a different candidate. All candidates need application handling for unknown write outcomes. A green candidate cell is not approval of the whole workload.*

9. Complete a hypothetical operation assessment

The fictional Meridian booking service has a strict seat reservation, a two-account payment ledger, an informational search listing and an expiring session record. Its original request also demands a Mumbai serving replica. No production workload or customer outcome is represented. The following entries show why one reassuring consistency label cannot admit the entire service.

The unchanged workload is rejected, not “mostly admitted.” A meaningful alternative is to revisit the Mumbai requirement, move the seat decision into an eligible MRSC table, and separately choose a regional transaction authority for payment with an explicit remote-observation contract. That is two new proposals with client-visible boundaries. If the payment requirement cannot weaken, the team needs a different joint-commit design, not a compromise hidden in a table score.

Another alternative retains MREC for eligible informational and regional-authority workloads. It must prove that independent writers cannot make the same authoritative seat decision. The cost of that authority and the changed remote experience belongs in the assessment. The paper does not choose a vendor for the rejected payment path without its full requirements.

The narrower fictional seat proposal can be made concrete without declaring the whole service admitted:

Proposal: Meridian seat reservation only, NOT EXECUTED
Assessment: October 7, 2026; same-account version 2019.11.21
Mode: proposed MRSC; separate table, not a mode per operation
Serving replicas: Ireland eu-west-1; London eu-west-2
Witness: Paris eu-west-3; no client endpoint or application traffic
Atomic boundary: one seat item, partition key seat#S42
Attributes: version, reservationId, acceptedOperationId
Initial hypothetical state: version 0; reservationId absent
Write path: UpdateItem at a serving regional endpoint
Precondition: version = :expected AND attribute_not_exists(reservationId)
Transition: set version 1, reservationId R9, acceptedOperationId op-42
Critical read: GetItem on the base table with ConsistentRead true
Index path: not used to decide reservation acceptance
External effects: confirmation is outside the item transition
TTL / LSI: neither required by this narrowed seat proposal
Unknown result: hold confirmation; reconcile exact operation identity
Unknown evidence: actual conflict handling, receipt behavior, permissions
Verdict: CANDIDATE item contract; HOLD implementation acceptance
Whole-service verdict: REJECT unchanged requirements listed above

The replacement Region choice deliberately changes the original Mumbai requirement. It is not a workaround that satisfies it. The proposed attributes are a data-model sketch, not a deployable schema or proof that all future reservation changes preserve the invariant. A cancellation, reassignment or second version transition needs its own operation row.

10. Unknown write outcomes need an application decision

AWS documents that a single-item write receiving an HTTP 500 may have succeeded or failed. Its error-handling guidance recommends reading state and/or using conditional expressions before retrying. A client timeout likewise does not supply a reliable business failure receipt. Record the observed error separately from the inferred operation outcome.

For a fictional seat request, preserve its operation ID, seat key, intended version transition and caller identity before sending. If the outcome is unknown, examine an authoritative base-item path and any operation receipt defined by the application. Seeing that the seat is reserved is insufficient if the record cannot identify whether this request or another request reserved it. A missing index entry is also insufficient because the index may lag.

The worksheet must define what happens when the state remains ambiguous: hold the confirmation, return a pending outcome, or send the operation to an approved reconciliation path. It must not automatically replay a provider charge or remove a precondition. This is an application policy proposal, not a claim that DynamoDB has supplied exactly-once execution.

For a supported regional transaction, the transaction API's client request token has a documented ten-minute idempotency window, with requirements for unchanged parameters. That bounded mechanism is not a durable business receipt and does not exist as a way to enable MRSC transactions. Cite the transaction contract in the applicable regional design rather than borrowing it across modes.

11. Treat creation and migration as separate designs

MRSC can be created from an existing empty table by adding the required replica configuration. The table must remain empty during conversion. Existing MRSC tables cannot simply add further replicas. Its documented three-Region topology and immutable mode constrain a proposed deployment before any application traffic is allowed. See global-table behavior.

An existing populated MREC table is not converted to MRSC by changing a consistency flag. An engineer must plan a new target, data transfer, identity preservation, validation and cutover boundaries. This paper intentionally provides no creation, deletion or migration command. An admission worksheet is not authorization to empty a table or run dual writers.

If evaluating a migration, record where writes are admitted during each stage, how duplicate operation identities survive transfer, and which reads can observe old versus new state. A copied item count cannot prove preservation of a business invariant. A dual-run comparison can be useful evidence but does not authorize two independent providers to execute the same external effect. Hand the selected proposal to the established migration and recovery owners rather than expanding this document into their runbook.

12. Review access, retention and economic inputs without changing the contract

Every serving replica and application endpoint needs an accountable access owner. Read the global-table security reference, then record the actual roles, resource scope, encryption ownership and approved configuration evidence. A strong consistency setting does not grant authorization or prove that every regional policy is equivalent. Do not use a broad permission grant to unblock a missing evidence field.

Region placement can also affect data-residency and retention requirements. A witness is non-serving, but its documented role still belongs in the proposed topology and compliance review. Do not label it “no data involvement” merely because clients cannot read it. If the team cannot establish the required copy and retention treatment, admission remains HOLD for that requirement.

The economic comparison requires dated inputs: serving replicas and witness choice, provisioned or on-demand mode, writes, reads by consistency path, replicated writes, indexes, item sizes, transfer and migration work. Use the current DynamoDB pricing reference and applicable account evidence when an authorized estimate is requested. No rate, achieved saving or latency target is manufactured here.

A cheaper candidate that violates a mandatory invariant remains rejected. Conversely, paying for MRSC does not repair a GSI membership requirement or unsupported transaction. Compare costs only after naming an admissible design and its changed application work. Unknown usage or future routing makes the estimate provisional, not a reason to substitute invented numbers.

13. Rehearse the contract in a bounded test design

The following are fictional expected classifications. The supplied local checks validate those classification rules and diagram geometry only. They do not emulate replication, prove race behavior or certify an AWS deployment. An actual rehearsal requires approved isolated resources, engine/API configuration evidence, bounded data, cleanup authority and a responsible operator. Do not run these against production as a shortcut.

For actual tests, preserve request identity, timestamps with clock source, keys, Region, API flags, response class and observation method. Avoid collecting customer payloads where keys and bounded synthetic records suffice. An authorization failure to read configuration is UNKNOWN, not proof that the feature is absent. Correlation by approximate timestamps alone is insufficient to attribute a confirmation or charge to one write.

14. Fillable operation matrix

Complete one record per authoritative operation. Add separate records for a listing or external effect if its guarantee differs. A blank or inaccessible mandatory field means HOLD, not a silently favorable assumption.

Assessment date / source-check date:
Proposal owner / accountable technical reviewer:
Global-table version / same-account boundary:
Proposed mode / exact Region roles / regional endpoints:

Operation name / stable operation identity:
Mandatory invariant, including when it must hold:
Accepted outcome and evidence that proves acceptance:
Item keys and attributes inside the atomic boundary:
Other items / provider effects outside that boundary:
Write API / condition / concurrent caller locations:
Read API / table or index / Region / consistency flag:
Allowed staleness / complete membership requirement:
Transaction requirement and observation scope:
TTL / LSI / retention requirement and replacement:
Unknown-outcome policy / duplicate policy / receipt path:
Required source contract / dated configuration evidence:
Permission or evidence gaps, explicitly UNKNOWN:
Verdict: REJECT / HOLD / CANDIDATE
Rejection reason or exact missing evidence:
Proposed alternative and changed client contract:
Bounded rehearsal cases / expected evidence / owner:
Observed rehearsal evidence: NOT EXECUTED until supplied
Open technical decisions / next review date:

Use a separate summary to decide whether every mandatory operation is admitted. Do not count candidate rows or weight them against rejection rows. Where two tables or an external service divide the work, record the boundary between them. The handoff itself can introduce an invariant that neither component establishes alone.

15. Decision record and limits

A useful completed decision is specific: “Reject unchanged MRSC for Meridian because the multi-item remote atomic payment, Mumbai serving placement and TTL dependency contradict its documented contract. Keep the single-item seat proposal as a separate candidate after revisiting placement. Hold unknown-outcome and actual concurrency evidence. Reject latest-complete GSI membership under both modes.” That is more actionable than “MRSC is stronger” or “global tables are eventually consistent.”

The source inventory is dated. Region availability and service constraints must be refreshed before implementation. The local fixtures cannot validate AWS behavior, application authority, payment-provider idempotency, customer acceptance, latency, cost or compliance. The examples do not establish measured savings, an AWS deployment or implementation acceptance.

The next step is to complete the operation records with the application's real requirements and approved configuration references, resolve mandatory rejections, and commission a separately authorized bounded rehearsal for the remaining candidates. Creation comes after the invariant is admissible, not before it is understood.