Transactions: Myths, Surprises and Opportunities

Transactions: Myths, Surprises andĀ Opportunities

Slides from a talk given at Strange Loop, 26 September 2015.


Back in the 1970s, the earliest databases had transactions. Then NoSQL abolished them. And now, perhaps, they are making a comeback... but reinvented.

The purpose of transactions is to make application code simpler, by reducing the amount of failure handling you need to do yourself. However, they have also gained a reputation for being slow and unscalable. With the traditional implementation of serializability (2-phase locking), that reputation was somewhat deserved.

In the last few years, there has been a resurgence of interest in transaction algorithms that perform well and scale well. This talk answers some of the biggest questions about the bright new landscape of transactions:

* What does ACID actually mean? What race conditions can you get with weak isolation (such as "read committed" and "repeatable read"), and how does this affect your application?
* What are the strongest guarantees we can achieve, while maintaining high availability and high performance at scale?
* How do the new generation of algorithms for distributed, highly-available transactions work?
* Linearizability, session guarantees, "consistency" and the much-misunderstood CAP theorem -- what's really going on here?
* When you move beyond a single database, e.g. doing stream processing, what are your options for maintaining transactional guarantees?


Martin Kleppmann

September 26, 2015