DynamoDB Transactions

DynamoDB Transactions extend DynamoDB's single-item ACID guarantees to multiple items across one or more tables. They provide full ACID compliance: Atomicity (all operations succeed or fail together), Consistency (data is consistent before and after the transaction), Isolation (intermediate states are invisible), and Durability (once committed, changes persist). Transactions are essential for use cases like financial transfers, order processing, and inventory management where multiple items must be updated in sync.

DynamoDB uses a two-phase commit protocol: Prepare and Commit. When you call TransactWriteItems or TransactGetItems, the following happens:

For reads (TransactGetItems), there is no lock; the items are read consistently across partitions, and the read is isolated from concurrent writes.

Transactions consume twice the write capacity units (WCUs) of a standard write. For a standard PutItem (1 KB item), 1 WCU is consumed. For the same item in a transaction, 2 WCUs are consumed (one for prepare, one for commit). Similarly, transactional reads consume twice the read capacity units (RCUs) of a standard strongly consistent read: 2 RCUs per 4 KB item (since a strongly consistent read normally costs 1 RCU per 4 KB, transactional read costs 2 RCUs). However, if the table uses on-demand capacity, there is no explicit capacity limit—but the cost per request is higher.

To prevent duplicate transactions due to retries, you can provide an idempotency token (ClientRequestToken) in the request. DynamoDB stores the token for 10 minutes after a successful transaction. If the same token is used again within 10 minutes, DynamoDB returns the previous response without re-executing the transaction. This is critical for retry logic in fault-tolerant applications.

If a transaction fails, DynamoDB returns a TransactionCanceledException with a list of CancellationReasons for each action. Common reasons:

DynamoDB Transactions provide serializable isolation for writes and read-committed for reads. Serializability means the result of concurrent transactions is equivalent to some serial execution. In practice, this prevents dirty reads, non-repeatable reads, and phantom reads for write transactions. For TransactGetItems, the isolation is read-committed, meaning it reads only committed data, but it does not prevent other transactions from modifying the data after the read.

When a transaction writes to a table with DynamoDB Streams enabled, each individual item modification generates a stream record. The stream records appear after the transaction commits. However, the stream does not indicate that the modification was part of a transaction; you must infer it from the application logic. This is important for downstream processing like Lambda triggers.

import boto3
from botocore.exceptions import ClientError

dynamodb = boto3.client('dynamodb')

try:
    response = dynamodb.transact_write_items(
        TransactItems=[
            {
                'Update': {
                    'TableName': 'Accounts',
                    'Key': {'AccountId': {'S': 'A123'}},
                    'UpdateExpression': 'SET balance = balance - :amt',
                    'ConditionExpression': 'balance >= :amt',
                    'ExpressionAttributeValues': {':amt': {'N': '100'}}
                }
            },
            {
                'Update': {
                    'TableName': 'Accounts',
                    'Key': {'AccountId': {'S': 'B456'}},
                    'UpdateExpression': 'SET balance = balance + :amt',
                    'ExpressionAttributeValues': {':amt': {'N': '100'}}
                }
            }
        ],
        ClientRequestToken='unique-token-123'
    )
    print("Transaction successful")
except ClientError as e:
    if e.response['Error']['Code'] == 'TransactionCanceledException':
        for cancel in e.response['CancellationReasons']:
            print(f"Action {cancel['Item']} failed: {cancel['Code']}")
    else:
        raise

A fintech company processes peer-to-peer payments. They use DynamoDB Transactions to atomically debit the sender's account and credit the recipient's account. Each account is a separate item in the same table, keyed by account ID. The transaction includes a ConditionExpression on the sender's item to ensure sufficient balance. The service uses an idempotency token derived from the payment ID to safely retry on network timeouts. In production, they handle thousands of transactions per second. Scaling considerations: they use on-demand capacity to avoid throttling during peak hours. They monitor the TransactionConflict metric; if it spikes, they reduce the number of items per transaction or optimize partition key design to avoid hot keys. A common misconfiguration is not using idempotency tokens, leading to duplicate payments when retries occur. They also ensure that the transaction does not exceed 4 MB; if a user has many pending transactions, they batch them into separate transactions.

An e-commerce platform uses DynamoDB to manage inventory and orders. When a customer places an order, a transaction decrements the inventory count for each item in the order and creates an order record. The inventory items are in one table, and the order record is in another. The transaction includes a ConditionCheck on each inventory item to ensure stock is available. If any item is out of stock, the entire transaction fails, and the order is not created. This avoids partial orders. They use strongly consistent reads via TransactGetItems to verify cart prices before checkout. A common pitfall is exceeding the 25-action limit when an order contains many items; they must split into multiple transactions or use a different pattern (e.g., reserve inventory separately). They also discovered that transactions with many items (close to 25) have higher latency and are more prone to conflicts, so they keep transactions small.

A gaming company maintains player profiles and game state in separate DynamoDB tables. When a player completes a quest, they earn experience points (XP) and unlock an achievement. The XP update goes to the player profile table, and the achievement record goes to the achievements table. They use a transaction to ensure both updates happen atomically. If the transaction fails due to a conflict (e.g., the player's profile is being updated by another transaction), they retry with exponential backoff. They use DynamoDB Streams on both tables to trigger downstream analytics. A challenge they faced: the transaction's idempotency token cache (10 minutes) is not sufficient for long-running retries; they implemented a custom idempotency layer using a separate table with TTL.