Tensions in Practice: Atomic visibility in tension with short independent steps¶
Reservation workflow · visibility boundaries
A workflow reserves a part and assigns its pickup slot. Where both changes fit inside one transaction-capable store, they can become visible together or neither can be published. Across separately committing services, the reservation may already be real when the pickup step fails. Releasing it then is another action with its own outcome, rather than a rewind of history.
Avoid visible partial completion
Keep other observers from seeing only one half of the intended change.
Keep steps short and independently serviceable
Avoid holding shared resources across the full duration of a multi-step workflow.
Why these aims pull against each other
The boundary that hides intermediate state can also hold resources for longer. Short local commits release that coupling but expose states that later compensation must address.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
One atomic boundary
Stage both records inside a supported transaction, then commit both or abort both.
- What it protects
- Other observers do not see a committed reservation without the paired pickup record.
- What it costs
- Keeping the transaction open consumes coordination resources and can block or abort competing work.
- When it fits
- Fits changes genuinely covered by one supported atomic boundary and a short enough operation to tolerate its contention.
Illustration note: The first option does not wrap arbitrary outside services in a fictitious database guarantee. The example chooses records the transaction can actually govern.
Commit then compensate
Commit the reservation locally; if the later pickup step fails, run a predefined release as a new operation.
- What it protects
- No transaction must hold resources over the entire cross-service workflow.
- What it costs
- Intermediate reservations are visible, and release itself can fail or leave effects that cannot be erased.
- When it fits
- Fits separate services with acceptable temporary states, authored compensations and a plan for failed or incomplete repair.
Illustration note: The successful-release branch is illustrative. Other observers may already have acted on the reservation; compensation is not a general restoration guarantee.
What this illustration does—and does not—establish
Transaction: Long-Running Transactions Cause Contention supplies the duration/coordination cost. Saga Pattern supplies the distinct forward repair and exposure of intermediate states.
- The illustration fixes one later-step failure and omits retries, idempotency and recovery ownership.
- A sent message, shipped item or other irreversible effect cannot be assumed erased by a compensating record.
Source entries
Transaction
Transaction: Long-Running Transactions Cause Contention supplies the conflict examined here.
Long-Running Transactions Cause Contention
- T3: Long-Running Transactions Cause Contention. Holding locks or snapshots open for long periods causes contention, deadlocks, and serializability failures. Distributed transactions magnify this. Failure mode: transactions are kept open across slow operations (external API calls, user input); concurrent transactions block or abort; throughput collapses; SAGAs or shorter transactions with explicit compensation should be used but aren't.
Saga Pattern
Supplies local commits, visible intermediate states, and the limits of compensation.
How it works
Unlike two-phase commit, no resource is locked across the whole process — so the saga trades global isolation for availability, and must reason explicitly about intermediate states other actors can see.
When it helps, and when it misleads
It misleads when a step's effect is genuinely irreversible and its "compensation" is only a partial offset — a shipped package, a sent notification, a disclosed record. Calling such a step compensable invites the quiet assumption that the saga restores the *exact* prior state, when at best it reaches an *acceptable* one under eventual consistency.