Designing Data-Intensive Applications, 2nd Edition

Chapter 8. Transactions

Some authors have claimed that general two-phase commit is too expensive to support, because of the performance or availability problems that it brings. We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

James Corbett et al., “Spanner: Google’s Globally-Distributed Database” (2012)

In the harsh reality of data systems, many things can go wrong:

• The database software or hardware may fail at any time (including in the middle of a write operation).

• The application may crash at any time (including halfway through a series of operations).

• Interruptions in the network can unexpectedly cut off the application from the database, or one database node from another.

• Several clients may write to the database at the same time, overwriting one another’s changes.

• A client may read data that doesn’t make sense because it has only partially been updated.

• Race conditions between clients can cause surprising bugs.

To be reliable, a system has to deal with all these types of faults and ensure that they don’t cause catastrophic failures. However, implementing fault-tolerance mechanisms is a lot of work. It requires careful thought about all the things that can go wrong and rigorous testing to ensure that the solutions that are implemented actually work.

For decades, transactions have been the mechanism of choice ...