# Pat's Big Deal, and Transaction Coordination

DevFeed: [Pat's Big Deal, and Transaction Coordination](<https://devfeed.tech/articles/pat-s-big-deal-and-transaction-coordination-12550.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2024/01/23/big-deal.html>)

Author: Marc Brooker

Published: 2024-01-23T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [scale](<https://devfeed.tech/tags/scale.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

The article examines Pat Helland's "BIG DEAL" for scalable online transaction processing: applications avoid concurrently updating the same key, while databases avoid coordinating transactions that update disjoint keys. It explains the resulting write-skew problem under snapshot isolation, illustrates the difference between snapshot isolation and serializability, and discusses the trade-offs application developers face when preserving scalability and business correctness.

## Source excerpt

Pat's Big Deal, and Transaction Coordination Working together towards a common goal. I have a lot of opinions about Pat Helland's CIDR'24 paper Scalable OLTP in the Cloud: What's the BIG DEAL?1. Most importantly, I like the BIG DEAL that he proposes: Scalable apps don't concurrently update the same key. Scalable DBs don't coordinate across disjoint TXs updating different keys. In exchange for fulfilling their sides of this big deal2 the application gets a database that can scale6, and the database gets a task to do that allows it to scale. The cost of this scalability, for the application developer, is having to deal with a weird concurrency phenomenon called write skew. In this post, we'll look at write skew, why not preventing it helps databases scale, and how we can alter Pat's big deal to prevent write skew and get serializability. In particular, we'll try answer two big questions: Is Pat's big deal the best deal available? Would a serializable big deal be better for application programmers? Snapshot Isolation The big deal experiences write skew because of the database isolation level that Pat chose: snapshot isolation. Other than this particular weird behavior, the application can pretend that concurrent transactions run in a serial total order, which makes application developer's lives easy. Nobody likes reasoning about concurrency, and reasoning about concurrency while correctly implementing business logic is pretty hard, so that's comforting. There are a lot of ways to talk about these concurrency anomalies in the database literature. Tens, at least. The one I think is most accessible to developers is Martin Kleppmann's Hermitage, a set of minimal tests that illustrate each of the weird things that databases users can experience. The test setup is super simple: create table test (id int primary key, value int); insert into test (id, value) values (1, 10), (2, 20); Next, we make two connections to the database we'll call A and B, and run a transaction through