A wise old man species of unknown origin once said, “Do. Or do not. There is no try.” This sage advice rings true whether you’re trying to levitate a 12,000-pound X-Wing from a Dagobah swamp or writing all-or-nothing database-cloud transactions. Sometimes close doesn’t cut it.
Take an online financial transaction. Let’s say you owe your friend for yesterday’s lunch. You open Venmo, find your friend, type in “10” for the $10 you want to send them, tack on a pizza emoji, and hit PAY. But then, weirdly enough, the notification you’re used to receiving seconds after that doesn’t appear. Something has gone wrong. So now what? Is your $10 lost in the electronic ether? Is your friend ever going to buy you lunch again?
In this case, you don’t want anything to write or update unless all the parts of the pizza-payback operation are complete. For this, we can turn to AWS DynamoDB transactions.
What are DynamoDB transactions?
DynamoDB is Amazon’s scalable, NoSQL database service. If you’ve ever worked with DynamoDB, you may have noticed things get complicated when you need to create multiple all-or-nothing operations within and across tables. That’s why, in late 2018, Amazon introduced DynamoDB transactions.
DynamoDB transactions are used to support mission-critical applications that require an all-or-nothing approach, even if there’s a disruption to the system. They allow cloud engineers to implement complicated business logic into a single atomic transaction, which can be made up of multiple related tasks. This means they’re really useful for handling order fulfillment and management, processing financial transactions, or building multiplayer games.
ACID: Bad for humans, great for transactions
If science fiction and video games have taught us anything, it’s that acid is bad. You don’t want to fall in it when jumping from one platform to the next, and if you’re dealing with a Xenomorph infestation, you’ll need to get clever with your extermination efforts lest you burn a hole through your ship – or yourself. But in the world of transactions, ACID is a very good thing.
The concept of ACID transactions predates DynamoDB transactions by a couple of decades. But DynamoDB transactions can be ACID transactions. ACID is an (awesome) acronym used to describe four ideal properties of a database transaction.
Atomic: Each transaction is treated as a single unit and cannot be partially completed – a critical ingredient to their all-or-nothing-ness.
Consistent: Transactions are valid and must leave the database in a valid state. This prevents databases from being corrupted or suffering from data integrity issues.
Isolated: Different transactions are not dependent on one another. Even if they’re treated in parallel or sequentially, the effect of the transactions are the same in the end.
Durable: A committed transaction will remain committed, because the data is written to disc and not just held in memory. So there will be no breakdown even in the event of a system failure, such as a power loss.
DynamoDB transactions in action
Returning to our pizza-payback situation from earlier, you can see why ACID transactions are critical to using the cloud successfully. There are multiple steps involved that happen almost simultaneously.
Receive the request to transfer money → Verify there are sufficient funds in the originating account → Debit the originating account → Credit the receiving account
These steps happen almost simultaneously and require an all-or-nothing execution. That’s why ACID transactions are critical to using the cloud successfully – and for paying back your pizza debts.