Use DynamoDB Transactions for ACID Guarantees Across Items (2026)

DynamoDB transactions aren’t just about making sure data is consistent; they’re about preventing operations from leaving the system in a half-baked, inconsistent state, even when multiple items are involved.

Let’s see this in action with a simple inventory management scenario. Imagine we have two items in DynamoDB: a Product item and an Inventory item.

Product Item:

{
  "productId": "PROD123",
  "name": "Super Widget",
  "price": 19.99
}

Inventory Item:

{
  "productId": "PROD123",
  "location": "WarehouseA",
  "quantity": 100
}

Now, we want to fulfill an order. This involves two operations:

1. Decrement the quantity in the Inventory item.
2. Potentially, if this is the last item, update a status on the Product item.

Without transactions, if the system crashes after decrementing the inventory but before updating the product status, we have a product that’s out of stock but still marked as available. That’s a problem.

Here’s how we’d do this with a DynamoDB Transaction Write:

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('YourInventoryTable') # Replace with your table name

transaction_id = "ORDER789" # A unique identifier for this transaction

response = table.transact_write_items(
    TransactItems=[
        {
            'Update': {
                'TableName': 'YourInventoryTable',
                'Key': {
                    'productId': 'PROD123',
                    'location': 'WarehouseA' # Assuming location is part of the key or a secondary index
                },
                'UpdateExpression': 'SET quantity = quantity - :val',
                'ExpressionAttributeValues': {
                    ':val': 5 # We're selling 5 units
                },
                'ConditionExpression': 'quantity >= :min_val',
                'ExpressionAttributeNames': {
                    '#q': 'quantity' # If quantity is part of a GSI or similar
                },
                'ReturnValuesOnConditionCheckFailure': 'ALL_OLD' # Useful for debugging
            }
        },
        {
            'Update': {
                'TableName': 'YourInventoryTable',
                'Key': {
                    'productId': 'PROD123'
                },
                'UpdateExpression': 'SET orderCount = orderCount + :val',
                'ExpressionAttributeValues': {
                    ':val': 1
                }
            }
        }
    ],
    ClientRequestToken=transaction_id # Optional, for idempotency
)

print(response)

The core problem transactions solve is atomicity across multiple operations. In DynamoDB, each Put, Update, or Delete operation is atomic on its own. But when you need to perform several of these operations and ensure they all succeed or all fail together, you need transactions. This is crucial for things like financial transfers, inventory management, or any system where partial updates would lead to data corruption or incorrect business logic.

Internally, DynamoDB uses a two-phase commit protocol for transactions. When you send a TransactWriteItems request, DynamoDB first writes the intentions of your operations to a log. It then attempts to acquire locks on all the items involved in the transaction. If it can acquire all the locks, it proceeds to apply the changes to the actual items. If any lock cannot be acquired (because another transaction is holding it, or the item doesn’t exist as expected), the entire transaction fails. If the transaction is committed, DynamoDB then cleans up the logs. This locking mechanism is what prevents race conditions and ensures that your transaction either fully completes or has no effect.

A key lever you control is the ConditionExpression. This allows you to add fine-grained checks within a transactional operation. For example, in the Update for inventory, we added ConditionExpression: 'quantity >= :min_val'. This ensures that if the current quantity is less than the amount we’re trying to sell, the entire transaction will fail before any changes are committed. This is incredibly powerful for maintaining business rules.

One thing most people don’t know is how DynamoDB handles concurrent transactions. If two transactions try to modify the same item, one will acquire the lock first. The other transaction will then fail with a TransactionConflict error. Your application code must be prepared to handle these conflicts, typically by retrying the entire transaction. The ClientRequestToken parameter helps make these retries idempotent, meaning you can safely resend the same request multiple times without unintended side effects.

The next concept you’ll likely explore is how to handle transactional operations that involve reading items and then writing based on those reads, known as Read-Before-Write transactions, and the implications of the TransactionConflict exception.