DynamoDB Transactions and Conditional Writes

DynamoDB transactions provide ACID (Atomic, Consistent, Isolated, Durable) guarantees across one or more items within a single AWS account and region. They are designed for use cases where you must ensure that multiple items are updated, inserted, or deleted as a single, all-or-nothing operation. Conditional writes, on the other hand, are a lighter-weight mechanism that allows you to perform a write operation (PutItem, UpdateItem, DeleteItem) only if a specified condition is met on a single item. Both are critical for building correct, concurrent applications.

DynamoDB transactions use a two-phase commit protocol:

Phase 1 – Check (or Prepare): The transaction request includes a list of actions. DynamoDB first checks all preconditions (conditions specified in each action). For each item involved, DynamoDB acquires a lock on the item's partition (more precisely, on the item within its partition). The lock prevents other transactions or writes from modifying the item until the transaction completes. If any condition fails, DynamoDB releases all locks and returns a TransactionCanceledException with details about which condition failed.

Phase 2 – Commit: If all checks pass, DynamoDB applies the changes to all items atomically. It writes the new values and releases the locks. The entire operation is logged to the transaction log for durability. If a failure occurs during the commit phase (e.g., a node crash), DynamoDB automatically rolls back the transaction using the log.

Locking Behavior: Locks are held for the duration of the transaction, which is typically milliseconds but can be longer under contention. The default transaction timeout is 1 second. If a transaction does not complete within 1 second, it is cancelled and locks are released. This timeout is not configurable.

Throughput Consumption: Transactions consume twice the write capacity units (WCUs) or read capacity units (RCUs) compared to standard writes/reads. For a write transaction, each write consumes 2 WCUs (one for the prepare phase, one for the commit). For a read transaction (e.g., TransactGetItems), each item read consumes 2 RCUs. This is a common exam point.

Conditional writes are simpler: they allow you to specify a condition expression on a single-item write (PutItem, UpdateItem, DeleteItem). The write proceeds only if the condition evaluates to true. If the condition fails, the operation returns a ConditionalCheckFailedException and no write is performed. Conditions can check attribute values (e.g., attribute_not_exists(id), size > 10), attribute existence, or compare values.

Use Cases: Conditional writes are ideal for optimistic locking. For example, you can update an item only if its version attribute matches a known value. This prevents lost updates in concurrent scenarios.

Important: Conditional writes do not lock the item. They are atomic only at the single-item level. If two concurrent conditional writes check the same condition simultaneously, both may succeed if the condition is true at the time of evaluation. This is a race condition. To avoid this, use transactions or a version number with conditional writes (optimistic locking) and retry on failure.

Transaction API Operations: - TransactWriteItems – A batch of up to 25 write actions (Put, Update, Delete) across multiple items. Each action can have its own condition expression. - TransactGetItems – A batch of up to 25 read actions (Get) across multiple items. Returns consistent read (strongly consistent) by default.

Condition Expression: - Used in both transactions and conditional writes. - Syntax: attribute_exists | attribute_not_exists | attribute_type | begins_with | contains | size | comparison operators (=, <>, <, >, <=, >=, BETWEEN, IN). - Can combine with AND, OR, NOT, and parentheses.

Client Request Token (Idempotency): - For TransactWriteItems, you can provide a ClientRequestToken (a string) to make the transaction idempotent. If the same token is used within a 10-minute window, DynamoDB will not execute the transaction again but will return the previous result. This is crucial for retry logic.

Transaction Canceled Exception: - Contains a CancellationReasons list that details which action failed and why (e.g., ConditionalCheckFailed, TransactionConflict, None for successful actions).

DynamoDB Streams: Transactions generate stream records as normal writes/updates/deletes, but the stream records appear only after the transaction commits. If a transaction is rolled back, no stream records are emitted. This is important for downstream processing.

DAX (DynamoDB Accelerator): DAX is an in-memory cache that can be used with conditional writes and transactions? Actually, DAX does not support transactions. You cannot use DAX with TransactWriteItems or TransactGetItems. Also, conditional writes via DAX are not supported – you must use the DynamoDB API directly for conditional operations.

Global Tables: Transactions are supported in global tables, but they are only atomic within a single region. Cross-region transactions are not atomic. If you need atomicity across regions, you must implement your own coordination.

There is no configuration to enable transactions – they are always available. However, you must have the appropriate IAM permissions: dynamodb:TransactWriteItems and dynamodb:TransactGetItems. Also, the table must have sufficient provisioned capacity or handle throttling via on-demand.

CLI Example – TransactWriteItems:

aws dynamodb transact-write-items --transact-items '[
  {
    "Put": {
      "TableName": "Orders",
      "Item": {
        "OrderID": {"S": "123"},
        "CustomerID": {"S": "C456"},
        "Total": {"N": "100"}
      },
      "ConditionExpression": "attribute_not_exists(OrderID)"
    }
  },
  {
    "Update": {
      "TableName": "Accounts",
      "Key": {"AccountID": {"S": "A789"}},
      "UpdateExpression": "SET balance = balance - :amount",
      "ConditionExpression": "balance >= :amount",
      "ExpressionAttributeValues": {
        ":amount": {"N": "100"}
      }
    }
  }
]'

CLI Example – Conditional Write (PutItem):

aws dynamodb put-item \
    --table-name Products \
    --item '{"ProductID": {"S": "P001"}, "Price": {"N": "25"}}' \
    --condition-expression "attribute_not_exists(ProductID)"

Error Handling: - For conditional writes, catch ConditionalCheckFailedException. - For transactions, catch TransactionCanceledException and inspect CancellationReasons.

Transactions have higher latency than individual writes because of the two-phase commit and locking. They also consume more capacity units. Use transactions only when you truly need multi-item atomicity. For single-item atomic updates, use conditional writes with optimistic locking.

Contention: If multiple transactions try to access the same item simultaneously, some will fail with a TransactionConflict exception (part of CancellationReasons). You should implement retry logic with exponential backoff.

Item Size Limit: The maximum item size in DynamoDB is 400 KB. For transactions, the total size of all items in a single transaction cannot exceed 4 MB (for write transactions) and 4 MB for read transactions. This is an exam detail.

Number of Actions: Up to 25 actions per transaction (read or write).

Scenario 1: E-Commerce Order Processing

An e-commerce platform uses DynamoDB to store orders and inventory. When a customer places an order, the system must deduct the quantity from the inventory table and create an order record atomically. Without transactions, if the inventory deduction succeeds but the order creation fails, the inventory is lost. Using TransactWriteItems, the platform includes a Update action on the inventory item (with a condition that stock >= requested quantity) and a Put action on the orders table. If the inventory is insufficient, the entire transaction fails, and no order is created. In production, this system handles thousands of orders per second. The main challenge is contention on popular items – multiple customers may try to order the same item simultaneously, causing TransactionConflict exceptions. The solution is to use optimistic concurrency with a version number and retry logic. The inventory item includes a version attribute; the condition checks that the version hasn't changed. On conflict, the client retries with the new version. This pattern is common in high-traffic e-commerce.

Scenario 2: Financial Ledger System

A fintech company maintains a ledger of account balances in DynamoDB. When a transfer occurs between two accounts, both the debit and credit must happen atomically. Using TransactWriteItems, the system performs an Update on the sender's account (with condition balance >= amount) and an Update on the receiver's account. If the sender has insufficient funds, the transaction fails. In production, the system processes millions of transactions daily. The transaction timeout of 1 second is rarely an issue, but during peak load, throttling can occur. The system uses on-demand capacity to handle spikes. A common mistake is to use separate conditional writes instead of a transaction – this can lead to a scenario where the debit succeeds but the credit fails, causing data inconsistency. The exam tests this exact scenario: when you need atomicity across multiple items, you must use a transaction.

Scenario 3: Multi-User Collaborative Editing

A document editing application stores document revisions in DynamoDB. Multiple users may edit the same document simultaneously. To prevent conflicts, the application uses conditional writes with a version number. Each document item has a version attribute. When a user saves changes, the application issues an UpdateItem with a condition that version == currentVersion. If another user has saved in the meantime, the condition fails, and the application retrieves the latest version and prompts the user to merge. This is an example of optimistic locking. Transactions are not needed here because only one item is updated per save. The exam often contrasts this use case (single-item) with the multi-item atomicity requirement where transactions are necessary.