DynamoDB prend-il en charge les transactions ?

Oui. DynamoDB prend en charge les transactions ACID via TransactWriteItems et TransactGetItems. Chaque transaction regroupe jusqu'à 100 actions sur une ou plusieurs tables du même compte et de la même Région en une seule opération tout ou rien, avec une limite de taille combinée de 4 MB. Si une action échoue, aucune n'est appliquée.

Les deux API de transaction

TransactWriteItems — regroupe des actions Put, Update, Delete et ConditionCheck de façon atomique. Synchrone et idempotente.
TransactGetItems — lit plusieurs éléments dans un instantané unique, atomique et cohérent.

Règles et limites

Jusqu'à 100 éléments par transaction, sur une ou plusieurs tables.
Toutes les tables doivent être dans le même compte et la même Région.
La taille combinée des éléments ne peut pas dépasser 4 MB.
Tu ne peux pas viser deux fois le même élément dans une transaction.
Sur les tables globales, les garanties ACID ne s'appliquent qu'à l'intérieur de la Région où la transaction s'est exécutée — les changements se répliquent vers les autres Régions après la validation, et les tables globales en mode de cohérence forte multi-Région (MRSC) ne prennent pas du tout en charge les API de transaction.

Ce que coûte l'atomicité

Le même élément, deux chemins, avec ReturnConsumedCapacity activé :

PutItem, one 920-byte item                 ConsumedCapacity 1
TransactWriteItems, the same single Put    ConsumedCapacity 2

Une écriture transactionnelle vaut deux écritures en capacité, et une lecture transactionnelle vaut deux lectures. Sur la durée, ce doublement est tout le compromis : 100 écritures par seconde d'éléments de 1 KB coûtent 164,25 $ par mois en on-demand dans us-east-1, ou 328,50 $ si chacune passe par une transaction. Le calculateur de tarifs a un réglage de cohérence transactionnelle pour exactement cette comparaison.

La reprise qui ne s'applique pas deux fois

Une transaction qui expire peut malgré tout avoir été validée : c'est donc la reprise qui est dangereuse, pas la transaction. ClientRequestToken est ce qui rend la reprise sûre. En envoyant deux fois la même transaction ADD counter :one sous un même token :

TransactWriteItems  (token order-4711)     200
TransactWriteItems  (token order-4711)     200
GetItem counter                            {"N": "1"}

Les deux appels ont réussi et le compteur n'a bougé qu'une fois. Le token reste valide 10 minutes après la fin de la première requête ; réutilise-le plus tard et le second appel est une nouvelle transaction, donc le compteur bouge à nouveau. Réutilise-le dans la fenêtre avec n'importe quel autre paramètre modifié et DynamoDB renvoie IdempotentParameterMismatch.

Transaction ou batch

Contrairement à BatchWriteItem, qui applique chaque élément indépendamment (certaines écritures peuvent aboutir pendant que d'autres échouent), une transaction est du tout ou rien — utilise-la quand une application partielle corromprait tes données.

Aller plus loin

Apprends les motifs dans les transactions DynamoDB, et construis les expressions de condition sur lesquelles elles reposent avec l'Expression Builder. Télécharge DynoTable pour mettre tes éditions d'éléments en staging sous forme de diffs vérifiables et les valider ensemble en un lot transactionnel.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; la limite de 100 actions et la fenêtre d'idempotence de 10 minutes ont été revérifiées le 2026-07-28.

Les valeurs de ConsumedCapacity et la relecture idempotente ont été reproduites le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 ; coûts mensuels calculés à partir du prix on-demand de l'unité de requête d'écriture en us-east-1 dans notre table de tarifs AWS synchronisée.