DynamoDB ClientRequestToken 8-hour TTL: handling retries after token expiry

Idempotent write safety beyond the token retention window

DynamoDB stores a ClientRequestToken for PutItem, UpdateItem, and DeleteItem operations for up to 8 hours. Within that window, retries with the same token return the original response without re-executing the write. After the token is purged, a retry with the same token executes as a new write, which can create duplicate items or overwrite attributes if the original write succeeded but the response was lost.

The service does not expose a configuration to extend the token TTL, and the token store is not inspectable. Conditional writes using ConditionExpression can provide longer-term deduplication, but they require the caller to know the expected attribute state — information that may be unavailable after a network partition or client crash. TransactWriteItems does not accept ClientRequestToken at all, so transaction idempotency must be implemented at the application layer. Global Tables add another dimension: tokens are not replicated across regions, so cross-region retries can still produce divergent writes.

Open questions

• What application-level patterns reliably achieve exactly-once semantics for retries that may occur days after the original request, without relying on a known prior attribute state?
• For TransactWriteItems, what is the minimal idempotency-key schema and condition-check logic that avoids write duplication while preserving transaction atomicity?
• In a Global Tables deployment, how should cross-region retry logic coordinate to prevent last-writer-wins conflicts when the same logical write is retried in multiple regions?