Design Invariants to Minimize Distributed Transactions Without Pretending They Never Matter

1. Start from the invariant, not from a ban on distributed transactions

A useful architecture question is not “How do we avoid transactions?” It is “What must never become false, who has authority to enforce that, and what is the smallest coordination boundary that preserves it?” AtlasMart has different invariants: inventory must not be oversold, a payment must not be captured twice, search may lag catalog, loyalty points can often reconcile later, and an order history must remain auditable.

Some invariants can be moved into one owner. Some can be relaxed with explicit business semantics such as reservations. Some can be partitioned with escrow-like allocations, where each region has a bounded right to consume a portion of a global resource without coordinating every local action. Others still require a strongly coordinated decision.

2. Coordination minimization toolbox

3. AtlasMart lab: oversell versus bounded authority

The broken model gives both regions authority over the full stock of ten units and accepts twelve. The repaired model allocates six units to east and four to west, so each region can reserve locally without global coordination until an allocation transfer is needed. The same lab also uses an idempotency key to make payment capture retry-safe.

PHYSICAL_STOCK = 10

print("BROKEN: EACH REGION ACTS AS IF IT OWNS ALL STOCK")
regional_views = {"east": 10, "west": 10}
orders = {"east": 6, "west": 6}
accepted = sum(orders.values())
print("accepted units:", accepted, "physical stock:", PHYSICAL_STOCK, "oversold:", accepted > PHYSICAL_STOCK)

print("\nREFACTORED: ESCROW-LIKE REGIONAL ALLOCATIONS")
allocations = {"east": 6, "west": 4}
used = {"east": 0, "west": 0}

def reserve(region, qty):
    if used[region] + qty > allocations[region]:
        return False
    used[region] += qty
    return True

print("east reserve 5:", reserve("east", 5), used)
print("west reserve 6 rejected:", not reserve("west", 6), used)
print("west reserve 4:", reserve("west", 4), used)
print("total used <= physical:", sum(used.values()) <= PHYSICAL_STOCK)

print("\nWHEN COORDINATION IS STILL REQUIRED")
need = 1
transfer_possible = allocations["east"] - used["east"] >= need
print("west needs one more unit; east spare exists:", transfer_possible)
if transfer_possible:
    allocations["east"] -= need
    allocations["west"] += need
    print("coordinated transfer complete:", allocations)
    print("west reserve after transfer:", reserve("west", 1), used)
print("safe choices: coordinate an allocation transfer, wait, or reject")
print("unsafe choice: let west exceed its authority and reconcile later")

idempotency = set()
def capture(payment_key):
    if payment_key in idempotency:
        return "duplicate-rejected"
    idempotency.add(payment_key)
    return "captured"
print("payment capture #1:", capture("pay:o-400"))
print("payment capture retry:", capture("pay:o-400"))

4. What weaker guarantees actually cost

Weakening coordination transfers cost elsewhere. Eventual search requires freshness indicators and rebuild jobs. Asynchronous loyalty posting requires deduplication and reconciliation. Regional inventory allocation needs capacity headroom, transfer protocols, and potentially lower utilization because spare stock can be stranded in another region. A saga may increase business complexity through compensations and intermediate states. “No distributed transaction” is not free; it is a trade of one mechanism for another.

Coordination avoidance research frames this rigorously: only operations that preserve application invariants under independent execution can safely avoid coordination. If independently valid local operations can combine into an invalid global state, some coordination, partitioned authority, or redesigned invariant is necessary.

5. Cases that still deserve stronger coordination

Examples include a unique legal identifier that must be globally exclusive at creation time, a financial transfer whose debit and credit must atomically share one ledger invariant, or a resource transfer between regional escrow pools. You may still choose a saga or ledger-specific pattern, but the invariant must remain explicit. If the design says “we will reconcile later,” state what temporary violation is allowed, how long, who absorbs loss, and how repair is verified.

6. Production judgment and bridge to consensus

For each invariant, record the owner, atomic unit, tolerated anomaly, timeout semantics, retry/idempotency rule, durability, repair/reconciliation path, failure domains, and observability. Test partitioned ownership, duplicate requests, restore from backup, stale clients, operator mistakes, and migration rollback. The next chapter introduces consensus precisely: the mechanism used when a group must agree on a value or leader under specified failure assumptions. Consensus is not a synonym for every transaction, but it often underpins the stronger coordination primitives used in this chapter.

References

Foundational claims are vendor-neutral. Product documentation is used only as a current implementation example and is not required for the mandatory labs.

• Bailis et al. — Coordination Avoidance in Database Systems — Invariant-confluence framework for reasoning about when coordination can be safely avoided.
• PostgreSQL 18 — Two-Phase Transactions — Current implementation example showing that stronger multi-resource coordination remains a legitimate tool with operational costs.
• Garcia-Molina & Salem — Sagas — Primary reference for compensation-based long-lived workflows when one atomic transaction is not the chosen boundary.
• Apache Cassandra — Guarantees — Current example of consensus-backed conditional operations as a narrower coordination primitive.