DynamoDB TransactionConflictException

TL;DR — Another transaction is already operating on the same item as your request, so DynamoDB rejected yours to preserve isolation. It's transient contention, not a bug in your data — retry with exponential backoff, keep transactions small, and cut down concurrent writes to the same hot item.

What it means

TransactionConflictException: Transaction is ongoing for the item

DynamoDB serializes conflicting transactional writes. You hit this when a PutItem/UpdateItem/DeleteItem or a TransactWriteItems item collides with another in-flight TransactWriteItems that includes the same item. Rather than block, DynamoDB fails the losing request with TransactionConflictException (HTTP 400). It is retryable — the conflict clears once the other transaction commits or aborts.

Note the distinction from TransactionCanceledException: a cancellation reports why a whole transaction was rolled back (a failed condition, capacity, or a conflict) via CancellationReasons, and TransactionConflict can appear there as one item's reason.

Why it happens

• Concurrent writes to the same item — a plain PutItem/UpdateItem overlaps an in-flight TransactWriteItems touching that item.
• Two transactions sharing an item — two TransactWriteItems requests include the same key at the same time; one wins, the other conflicts.
• A hot item under heavy concurrent updates — e.g. a shared counter or a single aggregate row every request updates.
• Long or large transactions holding items long enough to overlap other writers.
• A retry storm — retries without backoff pile more concurrent attempts onto the same contended item.

How to fix it

1. Retry with exponential backoff + jitter. This is the primary fix — the conflict is transient. The AWS SDKs retry it, but keep jitter so retries don't resynchronize into another collision.
2. Keep transactions small and short — fewer items per TransactWriteItems means shorter holds and less overlap.
3. Reduce contention on hot items — shard a hot counter across multiple items and aggregate, or use an atomic counter with a plain UpdateItem (ADD) instead of a transaction when you don't need all-or-nothing semantics.
4. Don't mix a transaction and a plain write on the same item concurrently if you can avoid it — route both through the same path.
5. Monitor the TransactionConflict CloudWatch metric to see whether contention is rising and where.

FAQ

How do I fix TransactionConflictException in DynamoDB? Retry the request with exponential backoff and jitter — the conflict is transient contention with another in-flight transaction on the same item. Also keep transactions small, shard hot items, and avoid running a transaction and a plain write against the same item concurrently.

Is TransactionConflictException the same as TransactionCanceledException? No. TransactionConflictException means another transaction is currently operating on the item. TransactionCanceledException means a whole transaction was rolled back; its CancellationReasons explain why, and a transaction conflict can be one of those reasons.

Related errors

• TransactionCanceledException — a whole transaction rolled back (conditions, capacity, or a conflict).
• ConditionalCheckFailedException — a single write's condition failed.
• Learn: DynamoDB transactions · Atomic counters