Lectures DynamoDB fortement cohérentes vs à cohérence à terme

Tu mets à jour un item, tu le relis immédiatement, et tu obtiens l'ancienne valeur. L'écriture a réussi — un instant plus tard la même lecture renvoie la nouvelle valeur. Rien n'est cassé : tu as heurté la lecture à cohérence à terme par défaut de DynamoDB, et tu peux t'en désengager par requête.

C'est l'un des rares boutons de correction que DynamoDB te confie directement, et il a un vrai prix attaché. Le maîtriser, c'est savoir ce que chaque mode garantit, ce qu'il coûte, et là où les lectures fortes ne sont tout simplement pas disponibles.

Quelle est la différence entre les lectures fortement cohérentes et à cohérence à terme dans DynamoDB ?

Une lecture à cohérence à terme (le défaut) est servie par n'importe quel réplica, elle peut donc renvoyer brièvement des données périmées juste après une écriture, mais elle coûte moitié moins cher. Une lecture fortement cohérente, à activer par requête avec ConsistentRead=true, est routée vers le leader de la partition et reflète toujours chaque écriture validée — pour 2× la capacité de lecture.

• À cohérence à terme (le défaut) — peut brièvement renvoyer des données périmées juste après une écriture. Le mode de lecture le moins cher.
• Fortement cohérent — reflète toujours chaque écriture validée avant la lecture. À activer par requête avec ConsistentRead=true.
• Les lectures fortes coûtent 2× les lectures à terme. Une lecture fortement cohérente consomme deux fois la capacité de lecture d'une lecture à cohérence à terme pour les mêmes données.
• Pas partout. Tu obtiens des lectures fortes sur la table de base et sur un Local Secondary Index. Un Global Secondary Index est à cohérence à terme uniquement — aucune option d'activation.
• Mets le défaut sur la cohérence à terme. Ne recours au mode fort que lorsque tu lis tes propres données tout juste écrites et qu'un retard d'un instant serait incorrect.

Le problème : une lecture qui ne voit pas la dernière écriture

Disons que tu gères des comptes utilisateurs. Un utilisateur change son email de notification, ton appli écrit la mise à jour, et l'écran de confirmation relit immédiatement le profil pour afficher la nouvelle adresse. Avec le mode de lecture par défaut, cette relecture peut atterrir sur un réplica qui n'a pas encore reçu le changement — l'utilisateur voit donc son ancien email et croit que la sauvegarde a échoué.

La fenêtre est petite (typiquement bien en dessous de la seconde) et elle se referme d'elle-même. Mais « habituellement correct » n'est pas suffisant pour une confirmation de lecture-après-écriture. C'est exactement le cas pour lequel la cohérence forte existe.

Pourquoi la cohérence à terme se produit

DynamoDB stocke chaque partition sur trois nœuds de stockage — un primaire et deux réplicas — répartis sur des zones de disponibilité distinctes. Une écriture est acquittée dès qu'elle atterrit sur le primaire et un réplica ; elle se propage ensuite vers le troisième nœud de façon asynchrone.

Les lectures, pour répartir la charge, peuvent être servies par n'importe lequel des trois nœuds. Une lecture à cohérence à terme peut heurter un nœud qui n'a pas encore reçu ta plus récente écriture — elle renvoie donc une valeur légèrement périmée. Une lecture fortement cohérente est routée vers le leader de la partition, qui détient toujours les dernières données validées, et ne renvoie donc jamais de résultat périmé.

Ce retard de réplication est toute la différence. Il explique aussi le coût de 2× : les lectures fortes ne peuvent pas être réparties sur les réplicas comme le sont les lectures à terme, donc DynamoDB les facture au double de la capacité.

Le coût, rendu concret

Les lectures sont mesurées en Read Capacity Units (RCU), chacune couvrant jusqu'à 4 Ko. Une RCU achète une lecture fortement cohérente ou deux lectures à cohérence à terme d'un item de 4 Ko. Donc activer ConsistentRead=true sur un chemin de lecture chaud double son coût de lecture — sur un endpoint à fort trafic, c'est une ligne de facture que tu remarqueras.

Modélise la différence pour tes propres tailles d'items et débits de requêtes avec le calculateur de tarification DynamoDB avant de faire des lectures fortes ton défaut — ça vaut rarement le coup de payer le double partout.

Où les lectures fortes sont (et ne sont pas) disponibles

Un GSI maintient sa propre copie des données, répliquée depuis la table de base de façon asynchrone, il ne peut donc jamais offrir de lecture forte. Si un motif d'accès a véritablement besoin de lecture-après-écriture et que tu comptais le servir depuis un GSI, c'est un signal pour le servir plutôt depuis la table de base ou un LSI.

Pièges et étapes suivantes

• Ne fais pas des lectures fortes le défaut. La plupart des lectures tolèrent une fenêtre de péremption inférieure à la seconde ; payer 2× partout est de la dépense gâchée.
• N'attends pas de lecture-après-écriture d'un GSI. Il est à cohérence à terme par conception — vois pourquoi un GSI est à cohérence à terme.
• Les transactions lisent fortement. TransactGetItems est toujours fortement cohérent — vois les transactions DynamoDB.
• La cohérence interagit avec la capacité. Le multiplicateur de 2× se rattache directement à la planification de coût on-demand vs provisioned.

Tu veux explorer tes tables et index DynamoDB sans écrire d'appels API ? Télécharge DynoTable et inspecte tes données directement.