DynamoDB Streams

DynamoDB Streams est un journal de capture des changements (change data capture) : chaque insertion, mise à jour et suppression sur une table est capturée, dans l'ordre, sous forme de flux d'enregistrements auxquels tu peux réagir. C'est ainsi que tu transformes une table en source d'événements sans la sonder en boucle.

Dans le scénario du journal d'audit, tu veux réagir à l'instant où un événement sensible atterrit — déclencher une alerte quand quelqu'un exporte une facture ou accorde un rôle admin — sans scanner la table sur un minuteur. Streams est le côté push de tout ça.

Comment fonctionne DynamoDB Streams ?

DynamoDB Streams capture chaque insertion, mise à jour et suppression sur une table sous forme de journal ordonné dans le temps et dédupliqué, conservé jusqu'à 24 heures. Tu choisis ce que porte chaque enregistrement via StreamViewType (clés seules, nouvelle image, ancienne image, ou les deux), puis tu consommes le stream avec un déclencheur Lambda pour réagir aux changements d'items sans sondage.

• Streams capture les changements au niveau de l'item sous forme de journal ordonné dans le temps et dédupliqué, conservé pendant jusqu'à 24 heures.
• Tu choisis ce que porte chaque enregistrement via StreamViewType : les clés seules, la nouvelle image, l'ancienne image, ou les deux.
• Les enregistrements sont ordonnés au sein d'une clé de partition, et un stream est partitionné de la même façon que la table.
• Le consommateur natif est Lambda — un déclencheur qui s'exécute par lot de nouveaux enregistrements, avec Kinesis Data Streams comme alternative pour un fan-out plus riche.

Le problème : réagir sans sondage

Tu as besoin de « préviens-moi quand un événement role.granted est écrit ». L'approche naïve est un job planifié qui scanne pour de nouveaux événements chaque minute — ce qui lit toute la partition récente à chaque fois, coûte de la capacité, et a toujours au moins une minute de retard.

Ce que tu veux vraiment, c'est un push : DynamoDB te prévient à l'instant où un item change. C'est exactement ce que fournit Streams, avec l'enregistrement de changement livré à ton code au lieu que ce soit toi qui le traques.

Comment fonctionne Streams

D'après la documentation AWS, DynamoDB Streams stocke « un journal dédupliqué et ordonné dans le temps des changements pendant jusqu'à 24 heures » avec une intégration Lambda native (capture des changements pour DynamoDB). Chaque enregistrement décrit une modification au niveau d'un item.

Quand tu actives un stream, tu choisis un StreamViewType, qui contrôle la part de l'item modifié que porte chaque enregistrement :

Les enregistrements sont ordonnés au sein de chaque clé de partition et le stream est partitionné selon la même structure de partition que la table. La rétention est de 24 heures — Streams est un tampon de réaction, pas un historique permanent. Pour un historique durable, tu stockes les événements eux-mêmes (ce qui est exactement ce qu'est déjà notre table de journal d'audit).

Le consommateur natif est un déclencheur Lambda : DynamoDB invoque ta fonction avec un lot de nouveaux enregistrements de stream à mesure qu'ils arrivent.

Un exemple concret : alerter sur les événements d'audit sensibles

La table de journal d'audit reçoit un stream avec NEW_IMAGE, donc chaque enregistrement porte le nouvel événement complet. Une Lambda consomme le lot et ne transmet que les enregistrements qui comptent :

La fonction ne touche jamais la table — elle réagit purement à ce que le stream lui remet. Pas de sondage, pas de scan, et l'alerte se déclenche en quelques secondes après l'écriture. Parce que les enregistrements sont ordonnés par clé de partition, tous les événements d'un même tenant arrivent dans l'ordre où ils ont été écrits.

C'est aussi la façon standard de maintenir une copie en aval : un consommateur de stream peut projeter chaque événement dans OpenSearch pour une recherche d'audit en texte intégral, ou agréger des comptes — le tout dérivé du même journal de changements.

Fais-le dans DynoTable

Avant de câbler un consommateur de stream, tu dois connaître la forme exacte de l'item que ta Lambda va recevoir — quels attributs existent, à quoi ressemblent les maps et listes imbriquées, ce qu'un enregistrement NEW_IMAGE contiendra réellement.

Pour convertir un item échantillon entre du JSON simple et la forme attribute-value qu'utilise un enregistrement de stream, le convertisseur DynamoDB JSON le fait dans ton navigateur. Et dans DynoTable, tu peux inspecter l'item complet — y compris sa forme DynamoDB-JSON — pour modéliser l'enregistrement NEW_IMAGE à partir de données réelles plutôt que de deviner la forme des champs.

Si tu testes un consommateur en local, fais tourner la table contre DynamoDB Local et inspecte-la de la même façon — voir se connecter à DynamoDB Local.

Pièges et étapes suivantes

• 24 heures, ce n'est pas un backlog. Si ton consommateur est hors service pendant une journée, les enregistrements expirent et sont perdus. Streams est fait pour une réaction quasi temps réel, pas pour un rejeu durable — garde les événements eux-mêmes pour l'historique.
• Choisis le plus petit StreamViewType dont tu as besoin. NEW_AND_OLD_IMAGES double le payload ; si tu n'as besoin que de la clé pour aller relire l'item, KEYS_ONLY est moins cher.
• L'ordre est par clé de partition, pas global. Les événements de deux tenants différents n'ont aucune garantie d'ordre entre eux — seulement au sein de la partition d'un même tenant.
• Les suppressions par TTL apparaissent comme des enregistrements de stream avec le marqueur d'attribut système, ce qui te permet d'archiver les items qui expirent — voir DynamoDB TTL.

Streams transforme le journal d'audit en source d'événements. La préoccupation opérationnelle suivante est l'extrémité opposée de la vie d'un item — faire expirer les vieux événements automatiquement avec DynamoDB TTL.

Télécharge DynoTable pour inspecter la forme exacte de l'item que ton consommateur de stream recevra avant d'écrire une seule ligne de code Lambda.