# Atomic Commitment: The Unscalability Protocol

DevFeed: [Atomic Commitment: The Unscalability Protocol](<https://devfeed.tech/articles/atomic-commitment-the-unscalability-protocol-12525.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2022/10/04/commitment.html>)

Author: Marc Brooker

Published: 2022-10-04T00:00:00Z

Content type: opinion

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: [Transactions](<https://devfeed.tech/topics/transactions.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Database](<https://devfeed.tech/topics/database.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Computer science](<https://devfeed.tech/topics/computer-science.md>), [data](<https://devfeed.tech/topics/data.md>), [dataset](<https://devfeed.tech/topics/dataset.md>)

Tags: [atomic](<https://devfeed.tech/tags/atomic.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [database](<https://devfeed.tech/tags/database.md>), [routing](<https://devfeed.tech/tags/routing.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [speed](<https://devfeed.tech/tags/speed.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

The article explains why atomic commitment can limit scalability in sharded databases. It contrasts single-row operations, which can be routed to individual shards, with distributed transactions that may require atomic writes across multiple machines. Using two-phase commit as the classic solution, it shows that throughput depends on the mean number of shards visited by each transaction: single-shard transactions can scale, while transactions spanning both shards provide no capacity increase.

## Source excerpt

Atomic Commitment: The Unscalability Protocol 2PC is my enemy. Let's consider a single database system, running on one box, good for 500 requests per second. ┌───────────────────┐ │ Database │ │(good for 500 rps) │ └───────────────────┘ What if we want to access that data more often than 500 times a second? If by access we mean read, we have a lot of options. If be access, we mean write or even perform arbitrary transactions on, we're in a trickier situation. Tricky problems aside, we forge ahead by splitting our dataset into two shards: ┌───────────────────┐ ┌───────────────────┐ │ Database shard 1 │ │ Database shard 2 │ │(good for 500 rps) │ │(good for 500 rps) │ └───────────────────┘ └───────────────────┘ If we're just doing single row reads and writes, we're most of the way there. We just need to add a routing layer that can decide which shard to send each access to, and we're done1: ┌────────────┐ │ Router │ └────────────┘ ┬ ┌─────────┴───────────┐ ▼ ▼ ┌───────────────────┐ ┌───────────────────┐ │ Database shard 1 │ │ Database shard 2 │ │(good for 500 rps) │ │(good for 500 rps) │ └───────────────────┘ └───────────────────┘ But what if we have transactions? To make the complexity reasonable, and speed us on our journey, let's define a transaction as an operation that does writes to multiple rows, based on some condition, atomically. By atomically we mean that either all the writes happen or none of them do. By based on some condition we mean the transactions can express ideas like "reduce my bank balance by R10 as long as it's over R10 already". But how do we ensure atomicity across multiple machines? This is a classic computer science problem called Atomic Commitment. The classic solution to this classic problem is Two-phase commit, maybe the most famous of all distributed protocols. There's a lot we could say about atomic commitment, or even just about two-phase commit. In this post, I'm going to focus on just one aspect: atomic commitment has weird scaling be