In 1983, Theo Härder and Andreas Reuter published a paper that gave a name to something database people had been building toward for more than a decade. ACID: atomicity, consistency, isolation, durability. Jim Gray had already assembled most of the pieces in a 1981 paper, working through bank transfers, car rentals, grocery purchases as his motivating examples. What Härder and Reuter added was compression. A decade of operational intuition, reduced to a contract you could hold in your head.
The contract turned out to be absurdly productive.
Atomicity is the one everybody remembers: the operation happens completely or it doesn't happen. Move $500 from checking to savings and there is no moment, observable or otherwise, where the money has left one account without arriving in the other. Consistency put the rules of the data inside the database, so you declared a constraint once instead of writing checking code around every path that touched it. Isolation let each transaction pretend it was the only thing running on the machine. And durability meant that once the commit came back, the write had survived whatever came next: power loss, kernel panic, somebody tripping over a cable.
Together, those four bought something none of them delivers alone. They bought permission to stop thinking about the middle. You never wrote the branch for what happens if the machine dies between step three and step four, because the database had already written it for you. Application logic could assume success or failure with nothing in between, and the assumption held.
Reservation systems, inventory management, payroll, accounting, anything where half-done is a synonym for wrong got built on top of that. The reason your bank balance is still correct after the data center loses power is that somebody decades ago decided a group of writes should be indivisible. If you have never once had to think about this, the abstraction is doing exactly what it was built to do.
Gray drew a careful line in those early papers, though, and everything that came later depends on it. He separated protected actions, database writes that could be rolled back, from real actions that could not. Handing cash out of an ATM is a real action. A rollback erases the record of a transaction; it does not un-hand somebody four twenties, un-send a confirmation email, un-print a boarding pass. The promise was always scoped to what the database owned.
For a long time, longer than you'd guess given how fast everything else moved, that scope was enough. One application, one database. The transaction boundary and the system boundary were the same line on the diagram. People built enormous, actually reliable software inside that line, and I spent years of my career running it. When something went wrong you read the transaction log, found the failure, and discovered the database had already cleaned up after itself. It was a solved problem, and I don't say that about much.
Then the boundary moved.