Transactions Interview Questions

They apply a set of actions all-or-nothing across one or more items (and tables). Either every write/condition succeeds or none persist. Use them when two items must not diverge, not as a default wrapper for every Put.

A transaction can include up to 100 unique items and 4 MB of data. Duplicate the same item twice in one transaction and the request fails. Bulk jobs that touch thousands of rows need chunking or a different pattern, not one giant transaction.

It asserts an item state without changing it—for example “account still exists and status is ACTIVE”—so the accompanying Puts/Updates only commit if that check holds. Failed checks cancel the whole transaction. It is the transactional cousin of a single-item ConditionExpression.

Each item in a TransactWrite consumes extra WCUs (commonly 2× the usual write). You pay for atomicity and isolation. Wrapping a lone Put in a transaction is usually wasted money unless you needed a check against another item.

Yes. TransactWriteItems may include items from multiple tables in the same account and region. That is how you atomically update an orders table and an inventory table. Cross-region or cross-account atomicity is not provided.

When only one item’s correctness matters: decrement stock if quantity >= 1, or increment a version if it still matches. Conditions on one item are cheaper and simpler than TransactWrite. Reach for transactions when two or more items must move together.

A condition failure means your expression was false (insufficient funds). A conflict means another transaction touched an overlapping item at the same time. Both surface as TransactionCanceledException with different CancellationReasons; retry logic should not treat them the same.

TransactWrite: Update debit with condition balance >= amount, Update credit, optional ConditionCheck that both accounts are open. Use idempotency keys so retries do not double-transfer. Two independent Updates can credit without debiting if the process crashes between calls.

Serializable isolation among transactional writes on those items: readers of a committed transaction see all of it or none. Non-transactional reads can still be eventually consistent. Mixing heavy non-transactional writes on the same hot items increases conflicts.

Retry conflicts with jittered backoff; do not blindly retry condition failures without re-reading. Include a client request token or a ledger item so a successful retry after a timeout cannot apply twice. Infinite immediate retries on conflicts create a livelock on hot items.

Read CancellationReasons on TransactionCanceledException: ConditionalCheckFailed, TransactionConflict, ValidationError, and the item that caused it. Logging only “transaction failed” hides whether you should retry, fix data, or reduce overlap. Reasons are the interview-level detail.

Yes, projections happen as part of the committed write set. A throttled or limited GSI can still fail the transaction. Do not treat the GSI as a second transactional unique index; uniqueness belongs in conditions on base items.

Narrow the item’s write rate, split counters, or serialize that entity through a queue. Transactions isolate overlapping writes by failing one of them. If every request transacts on the same USER#1 balance item, conflicts become the product’s p99.

No. Atomicity is only among the actions inside the transaction API call. A following PutItem can succeed after the transaction fails, or vice versa. Application flows that need both must put every item into the same TransactWriteItems request.

Commit a short transaction that decrements stock and writes a RESERVED item with TTL, then confirm or cancel in a second transaction. Do not wait on a browser session inside one TransactWrite. Long-lived locks are not a DynamoDB primitive; expiry plus a state machine is.

When you touch many items per request, wrap every write “just in case,” or serialize a celebrity item. Extra WCUs and conflict retries dominate p99. High-QPS append-only event logs almost never want a 100-item transaction per event.

Each item change still emits its own stream record after commit; there is no single “transaction envelope” record. Consumers that must apply a multi-item business event atomically need a correlation id on the items or a separate outbox item. Designing for that avoids partial search updates.

Identify pairs that already must stay aligned, encode them as one transaction, and keep an idempotency ledger. Drop the prepare/commit tables once conflict rates and metrics look healthy. Half-migrated code that still does a lone write beside a transaction reintroduces the original race.

The 100-item and 4 MB caps, doubled WCUs, and conflict behavior make large copies slow and expensive. Use Import from S3, BatchWriteItem with backoff, or a warehouse pipeline. Transactions are for correctness of a business unit of work, not for loading last night’s dump.

Run parallel workers against the same keys in a local or dedicated table and assert only one transfer wins and balances still sum. Include timeout-retry cases with idempotency keys. A single-threaded unit test of TransactWrite never reveals the cancellation path interviewers care about.