--- title: "The Promise That Stopped at the Wire" canonical: "https://current.tinyfish.ai/issue/50/echoes/article/41588/the-promise-that-stopped-at-the-wire" publication: "TinyFish" publisher: "TinyFish" language: "en-US" guide: "https://current.tinyfish.ai/llms.txt" format: "Inside and Across Boundaries" author: "Sable Whitford" author_url: "https://current.tinyfish.ai/team/201" issue: 50 section: "echoes" section_name: "Echoes" published: 2026-10-08 updated: 2026-10-09 description: "Cross-system consistency broke every promise databases kept locally, and the workarounds agents inherit were never designed with them in mind." word_count: 656 source_links: 14 --- # The Promise That Stopped at the Wire *By [Sable Whitford]()* *October 8, 2026* [Read on the website]() The wall shows up the first time an application has to coordinate work across more than one system: two databases, or a database and a message queue, or a local service and somebody else's API out on the internet. Distributed systems history is largely people pushing on that wall and learning it's structural. The serious attempt was two-phase commit. Jim Gray's [1978 synthesis](https://jimgray.azurewebsites.net/papers/dbos.pdf) described it, and it reads as perfectly reasonable: a coordinator asks every participant whether it can commit, waits for unanimous yes, then announces the decision. One no and everybody aborts. It was formalized as the [XA standard](https://www.iso.org/standard/25721.html) and implemented in [PostgreSQL](https://www.postgresql.org/docs/current/two-phase.html) and [Oracle](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-distributed-transactions.html). The failure mode is where it comes apart. Two-phase commit preserves atomicity by [giving up availability](https://doi.org/10.1145/1132863.1132867): if the coordinator dies after participants have voted yes but before the decision is durably recorded, those participants sit there holding locks, unable to commit and unable to abort, waiting on a verdict that might be on a disk nobody can reach. PostgreSQL's documentation still warns that abandoned prepared transactions hold locks and can force a database shutdown. Nothing is broken, exactly. The protocol is doing what it was specified to do, and you are awake at 3 AM anyway. At web scale, the industry declined the trade. eBay's architects [said so plainly](https://www.cs.cornell.edu/projects/ladis2008/materials/eBayScalingOdyssey%20ShoupTravostino.pdf) in 2008: no two-phase commit, asynchronous events, eventual consistency. Pat Helland, who had spent years advocating distributed transaction platforms, [wrote in 2007](https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf) that the large projects built on them had foundered on performance cost and fragility. He changed his mind the expensive way, and eBay designed its architecture to stay out of cross-resource transactions entirely. It didn't die, though. [Google Spanner](https://research.google/pubs/spanner-googles-globally-distributed-database-2/) runs two-phase commit internally, across replica groups it controls end to end. [Amazon DynamoDB](https://www.usenix.org/system/files/atc23-idziorek.pdf) uses two-phase coordination for its ACID transactions. The distinction is ownership. Inside a system one operator runs, a stuck participant is somebody's pager and it comes back. Across services run by different companies, the protocol asks you to assume every participant stays up and reachable, and that assumption doesn't survive other people's outages. The pragmatic replacement came from a [1987 paper](https://doi.org/10.1145/38713.38742) by García-Molina and Salem. A saga splits a long operation into a sequence of local transactions, each paired with a compensating transaction; if the sequence fails partway, you run the compensations in reverse. The difference from an ACID rollback is the whole story. Those earlier local transactions already committed, and other processes may have seen the results and acted on them. Compensation is a new business action, cancel the reservation, issue the credit, not an erasure of what happened. As Sevda Polat [observed](https://current.tinyfish.ai/issue/47/echoes/article/38748) in an earlier piece here: > "The interface says the action was undone. Something stayed." The pattern persisted through [workflow research](https://doi.org/10.1109/COOPIS.1999.792183), compensation standards, and eventually the [microservices catalogs](https://microservices.io/patterns/data/saga.html). So did the bill. Uber [reported in 2021](https://www.uber.com/blog/fulfillment-platform-rearchitecture/) that its saga-based fulfillment platform produced intermediate inconsistencies requiring reconciliation, and moved core operations back inside Spanner transactions, shrinking the region compensation had to cover. Nobody landed on sagas everywhere or ACID everywhere. What settled is a boundary question, answered one system at a time: what stays inside a transactional zone, and what lives outside it, held together by compensation logic that a person wrote and a person watches? Agents work across those boundaries by construction. They call APIs, fill forms, trigger payments, move between systems that share no transaction manager and never will. They inherit forty years of consensus that strong cross-boundary consistency isn't practical across organizational lines, along with the workarounds that consensus produced, which all assume the same sequence: something goes partly wrong, a person notices, a person writes the correction, and a person handles it when the correction fails too. García-Molina and Salem were honest about that last case. They allowed that it might require manual intervention. Reasonable enough in 1987, when the thing that started the work was a person. Nobody has worked out what manual intervention means when it isn't. ## More - [Echoes — Issue 50]() - [Issue 50]() - [Publication guide]()