ACID Transactions Are Hard At Scale … Part 1
K.S. Bhaskar
… But YottaDB Does the Hard Work for You
What are ACID transactions?
ACID is an acronym for Atomic, Consistent, Isolated, and Durable.
Consider a transaction to transfer $100 from your savings account to your checking account. At a high level, it comprises at least the following steps:
- If there is sufficient balance in the savings account:
- Deduct $100 from your savings account balance.
- Add $100 to your checking account balance.
- Record information about the transaction, e.g., the origin of the request, authentication, whether it was authorized or denied (and if so, why), any service charges, etc.
Atomicity means that either all the steps need to be executed, or none of them need to be executed – you would be unhappy if the amount was deducted from your savings account but not deposited to your checking account, the bank would be unhappy if the amount was added to your checking account but not deducted from your savings account, the regulators would be unhappy if the transaction was not properly authorized and recorded, etc. If none of the steps happen, and you have enough balance in your savings account, you might be unhappy as a customer, but the bank and you are whole (“in balance”), and you can try again.
Durability means that once the transaction is completed, it is permanently recorded in the database and cannot be erased even if the computer crashes. If the bank later chooses to reverse the transaction, that would need to be a separate, second transaction. Durability will be the subject of a future blog post.
There is a duality to Consistency and Isolation. Consistency is the requirement that from a business perspective, the bank must be in compliance with business rules as determined by application logic. Consider two transactions executing at the same time (concurrently, but more about concurrency later). Both of them change the funds in accounts, and while they are executing, their temporary, private view is that the bank is not in balance (between steps 1a and 1b in the example above).
But when a process looks at any data other than what it is manipulating within the transaction, it should see the the bank as being in balance (Consistency). Isolation means that each transaction is executed as if it were the only transaction on the system. No application logic outside the transaction and executing concurrently with it should be able to see within the transaction, i.e., Isolation of a transaction provides Consistency for concurrent transactions.
So, for example, if there are two simultaneous requests to transfer funds from the savings account, and there are only enough funds for one, it is OK for one to be processed before the other, or the reverse, but each is processed as if it were the only transaction on the accounts. Of course, the second transaction would be rejected for lack of funds. Consistency and Isolation together imply serialization, that there is an order in which transactions are committed.
Why are ACID transactions hard at scale?
ACID transactions are conceptually simple. If an application processes only one transaction at a time, Consistency and Isolation are trivially implemented, while Atomicity and Durability only require a modicum of logic and programming effort. What makes them hard is scale. A large bank will at peak times process thousands to tens of thousands of transactions per second. Transaction processing at scale is challenging. In my thirty years in the database business, it has always been the case that as computers get faster, they are able to handle bigger workloads – but their ability to handle bigger workloads means that bigger workloads are thrown at them and push them to their limits. As the saying goes, “Every day, do more than what is expected of you, and soon more will be expected of you.”
The need to scale means that databases must execute in parallel the logic for multiple transactions, while ensuring ACID properties and serialization. The need to scale requires concurrency control. Concurrency control is the shepherding of the concurrently executing thousands to tens of thousands of transactions to get them committed with ACID properties. Concurrency control is just what make scaling ACID transactions hard.
Imagine you have a drive-through hamburger restaurant. You want to allow each hamburger to be customized, which means you can’t cook the patties in advance. Do you wait till an order is placed and then put patties on the grill, or when a car pulls into the parking lot, do you put a patty on the grill for each person in the car? If the former, then it takes more time to prepare each order. If the latter, you reduce the time to prepare each order, but you will have cooked patties leftover because not every person will order a hamburger.1 Concurrency control to deliver Consistency and Isolation at scale involves similar trade-offs.
To be continued in Part 2 …
Part 2 will discuss methods for concurrency control, and how YottaDB’s implementation of concurrency control allows it to deliver ACID transactions at scale.
But you don’t need to wait for Part 2. You can Get Started with YottaDB right now!
Footnotes
1 You could perhaps take each day’s leftover patties to make chilli con carne to serve the next day.
Credits
- Photo of transaction in Hanoi by Radek Kucharski used under CC BY 4.0.
- Image of Mandsur Opium Agency Hundi used under CC BY 4.0.
Published on January 22, 2026