‫So now let's talk about DynamoDB transactions.
‫And the idea is that with a transaction,
‫you're going to get an all-or-nothing operation
‫to multiple items across one or more tables.
‫So for example, we want to update,
‫delete or add items, not for just for one table,
‫but across multiple items.
‫And either all the transactions, all the writes work,
‫or none of them work.
‫This is why it's called a transaction.
‫Now this gives DynamoDB, the ACID feature.
‫So atomicity, consistency, isolation and durability.
‫Transactions can be applied into two things,
‫read modes and write modes.
‫For read modes, you're going to have three read modes.
‫Therefore in DynamoDB,
‫you're going to get eventual consistency,
‫strong consistency that we know before,
‫and now transactional consistency,
‫which means I want to read data from all these tables
‫at the same time and get a consistent view across it.
‫Transactionally, a consistent view across it.
‫And for write modes,
‫you're going to get standard and transactional.
‫So standard is you're going to do many writes
‫across many tables,
‫but some of them can fail.
‫But, transactional, either all the writes work
‫across all the tables,
‫or none of the writes work across all the tables.
‫Now to do a transaction,
‫it will consume twice the write capacity you need
‫and the read capacity units.
‫That's because anybody who will perform two operations
‫in the background for every item,
‫it will prepare the transaction and then commit it.
‫Now, these two operations you need to know
‫are going to be TransactGetItems,
‫is an API code to do one or more GetItem operations
‫as part of the transaction,
‫or TransactWriteItems to do one of more of PutItem,
‫UpdateItem, and DeleteItem operations
‫as part of one transaction.
‫The use cases for DynamoDB transactions is any time you
‫would have ACID needs.
‫So for example,
‫for financial transactions, for managing orders,
‫for multiplayer games, et cetera, et cetera,
‫everywhere you need some sort of consistency.
‫So let's take an example.
‫So we have AccountBalance,
‫which presents the account ID, the balance,
‫so how many dollars they are on each accounts,
‫and the last time a transaction was made onto this account.
‫And then we have another table called BankTransactions,
‫which represents all the transactions that happened
‫to the bank, okay?
‫And there's a transaction ID,
‫a transaction timestamp, From Accounts,
‫To Accounts, and the amount.
‫And so the idea is
‫that we want to, obviously, add a transactions
‫and modify the AccountBalance at the same time.
‫So our application is going to do one transaction.
‫And as part of this one transaction,
‫is going to do an UpdateItem on the AccountBalance,
‫and a PutItem on the BankTransactions.
‫Now with the DynamoDB transaction,
‫either the transaction is returned to both tables
‫at the same time or to none.
‫And this is the power of transactions.
‫And we can see,
‫especially in a financial setting like this,
‫that it is really, really important
‫to have these level of transaction guarantees.
‫So now let's talk about capacity computations
‫for DynamoDB, which is super important for the exam.
‫So if you want to do three transactional writes per second,
‫and the item size is five kilobytes,
‫what is it going to be the WCU needed?
‫Well, you're going to need three times five divided by one,
‫because one WCU is one kilobyte,
‫times two because transactional operations
‫are twice as expensive,
‫which makes you a need for 30 WCUs.
‫Now, if you have five transactional reads per second,
‫with items of size five kilobytes,
‫then you need five times eight divided by four times two,
‫because again, a transactional operation
‫is twice as expensive as a strongly consistent read,
‫which gives you 20 RCUs.
‫And why did we get eight?
‫Well, five did get rounded to the upper four kilobyte
‫that we've seen from before.
‫So be familiar with these computations,
‫be understanding of what a transaction is in DynamoDB.
‫I can't really demo in the console,
‫but I hope you liked this lecture
‫and I will see you in the next lecture.