What distributed transactions forbid

What this article forbids

Safe, non-blocking atomic commit with a single decision-holder in an asynchronous network.
Common knowledge over an unreliable channel, and therefore exactly-once delivery.
Availability better than the product of the participants' availabilities, for any decision that needs unanimity.
Compensation that undoes an observation (you cannot make someone un-see a value).
Ordering transactions by real time without either bounded clock uncertainty or communication between them.

Escapes and their prices

Escape	Price
Replicate every single point	Consensus latency
Store the decision in the data (Percolator)	A timestamp oracle and cleanup by readers
Remove the decision (Calvin)	Advance access sets, no interactivity
Abandon atomicity (sagas)	Visible intermediate states and a human queue
Move the second write inside the first's boundary (outbox)	Duplicates billed to the consumer
Make effects idempotent	A dedup store with a retention window you cannot validate
Buy tighter clocks	Money, plainly

Case, resolvedConstructed case · Tomas at Kestrel Tickets

Charged twice, or a seat with no e-ticket

After a payment-service crash some customers were charged twice and some had a seat but no e-ticket, and the proposed fix was two-phase commit across the database, the card gateway and the event bus. Where it started: Distributed transactions →

Lena's arithmetic on the whiteboard:

Participants. The card gateway offers no prepare phase. 2PC is not available. The capability check (step 2 of the procedure) ends the discussion before the performance numbers.
Even if it were available: the order touches seat rows that are hot in a flash sale. With two cross-service round trips of 5 ms each and fsyncs, lock hold time W goes from about 5 ms to about 20 ms. With the same arrival rate, L = λW rises 4 times, and the conflict pressure, which grows with L², rises about 16 times. And with five participants at 0.999, the purchase flow is available only 0.999⁵ ≈ 99.5% of the time (about 44 hours of unavailability per year, against about 9 hours for one component).

What Kestrel builds instead:

A saga. Reserve the seat in orders-db (compensator: release it). Authorize the card with payment-service and capture it. Send the e-ticket last, because it is the one step that cannot be undone: it becomes the commit point. If capture fails, the seat is released and no e-ticket is ever sent.
A transactional outbox. Marking the seat as sold (after the payment is captured) and writing the order.paid event are one local transaction in orders-db. A relay publishes to the event-bus through CDC. This removes the case "seat reserved, no event".
Idempotent consumers. The e-ticket service dedups on event_id. The payment call carries an idempotency key built from the order ID, so a retry after the crash of payment-service cannot charge twice. This removes "charged twice". The e-ticket service's dedup table keeps keys for 14 days, longer than the broker's retention of 7 days, so a late duplicate cannot slip through.
A reconciliation job and a human queue. Every night a job compares orders-db with the gateway's settlement report. Orders with a charge but no seat, or the reverse, go to a queue that support reads each morning. Lena states it plainly: the in-doubt outcome is irreducible; the job is how Kestrel pays for it.

Tomas does not get "all or nothing". He gets "everything eventually consistent, nothing charged twice, and a person who looks at what remains". That is the honest shape of a distributed transaction.