What transaction mechanics forbid

What this article forbids

Simultaneity. You may designate one write to stand for many; you can never perform many at once.
Removing the in-doubt window. Between issuing a durable write and learning its fate, the issuer does not know the outcome. This is true on one node as much as across ten.
Cheap commit and cheap abort together. Data placement picks one.
A commit rate above 1 / (latency of your atomic primitive) per independent committer. Batching raises throughput, but not the rate of individually ordered commits.
Conflict detection finer than your metadata's granularity. A file-level log cannot see a row-level conflict, whatever the isolation level is called.

Escapes and their prices

Escape	Price
Group commit	Latency for throughput (and it tunes itself)
Asynchronous commit	A bounded, explicitly sized durability window
Out-of-place placement	Space and a garbage collector, in exchange for free aborts
A single writer	A throughput ceiling and availability, in exchange for zero conflict
Partition-disjoint writers	A modelling constraint you must defend forever
Idempotency keys	Deduplication state with its own retention window

Case, resolvedConstructed case · Tomas at Kestrel Tickets

A timeout on COMMIT: did the top-up happen?

A wallet top-up whose COMMIT reply never arrived was paid twice when the customer retried, and a nightly lakehouse job lost 40 minutes of work to a commit conflict with another job. Where it started: Transaction mechanics →

The wallet top-up that timed out. Lena explains the three outcomes: committed, aborted, unknown. Tomas's code treated "no answer" as "failed" and let the customer pay again. The in-doubt window cannot be removed, so the design must make asking again safe. The top-up request now carries an idempotency key (a unique ID generated once, by the client, for that one intent). orders-db stores the key in a unique column inside the same transaction as the balance change. If the client retries after a timeout, either the key is found (the first attempt did commit, so return the same answer) or it is not (the first attempt did not commit, so apply it now). Money is neither doubled nor lost. The dedup table keeps keys for 7 days; a retry later than that would be applied twice, so the mobile app is limited to retry within 24 hours. This is a stated assumption, not a proof.

The lost 40 minutes. Lena computes the conflict unit: the nightly sales table has about 10,000 files, and each of the two jobs touches about 100 of them, so k²/N is about 1. The commit takes 50 ms, so the two jobs are in a regime six orders of magnitude worse than database rows. The fixes follow the rules above: the ingest job is the only writer during the night, the compaction job is moved to a window when ingest is off, and ingest writes in append-only mode, so a conflict can be rebased by retrying only the metadata step with jittered backoff, not by rewriting the Parquet files. The 04:10 failure costs one 50 ms round trip instead of 40 minutes.

She also adds one more item to the code review checklist: every read-only endpoint (seat map, order history) is marked READ ONLY.