DynamoDB Streams

DynamoDB Streams es un log de change-data-capture: cada inserción, actualización y borrado en una tabla se captura, en orden, como un flujo de registros ante los que puedes reaccionar. Es la forma de convertir una tabla en una fuente de eventos sin hacer polling sobre ella.

En el escenario del registro de auditoría quieres reaccionar en el instante en que aterriza un evento sensible — disparar una alerta cuando alguien exporta una factura o concede un rol de admin — sin escanear la tabla con un temporizador. Streams es el lado push de eso.

¿Cómo funcionan DynamoDB Streams?

DynamoDB Streams captura cada inserción, actualización y borrado en una tabla como un log ordenado en el tiempo y deduplicado, retenido hasta 24 horas. Tú eliges qué lleva cada registro con StreamViewType (solo las claves, la imagen nueva, la imagen antigua o ambas), y luego consumes el stream con un trigger de Lambda para reaccionar ante cambios en los Items sin hacer polling.

• Streams captura cambios a nivel de Item como un log ordenado en el tiempo y deduplicado, retenido durante hasta 24 horas.
• Tú eliges qué lleva cada registro vía StreamViewType: solo las claves, la imagen nueva, la imagen antigua, o tanto la antigua como la nueva.
• Los registros están ordenados dentro de una clave de partición, y un stream se fragmenta igual que la tabla.
• El consumidor nativo es Lambda — un disparador que se ejecuta por cada lote de registros nuevos, con Kinesis Data Streams como alternativa para un fan-out más rico.

El problema: reaccionar sin polling

Necesitas "avísame cuando se escriba un evento role.granted". El enfoque ingenuo es un trabajo programado que escanea en busca de eventos nuevos cada minuto — lo cual lee toda la partición reciente cada vez, cuesta capacidad y siempre llega al menos con un minuto de retraso.

Lo que realmente quieres es un push: DynamoDB te avisa en el momento en que un Item cambia. Eso es exactamente lo que proporciona Streams, con el registro del cambio entregado a tu código en lugar de que tú lo busques.

Cómo funciona Streams

Según la documentación de AWS, DynamoDB Streams almacena "un log deduplicado y ordenado en el tiempo de los cambios durante hasta 24 horas" con integración nativa con Lambda (change data capture para DynamoDB). Cada registro describe una modificación a nivel de Item.

Cuando activas un stream eliges un StreamViewType, que controla cuánto del Item modificado lleva cada registro:

Los registros están ordenados dentro de cada clave de partición y el stream se fragmenta según la misma estructura de partición que la tabla. La retención es de 24 horas — Streams es un búfer de reacción, no un historial permanente. Para un historial duradero almacenas los eventos en sí (que es exactamente lo que ya es nuestra tabla de registro de auditoría).

El consumidor nativo es un disparador de Lambda: DynamoDB invoca tu función con un lote de registros de stream nuevos a medida que llegan.

Un ejemplo práctico: alertar ante eventos de auditoría sensibles

La tabla de registro de auditoría tiene un stream con NEW_IMAGE, así que cada registro lleva el nuevo evento completo. Una Lambda consume el lote y reenvía solo los registros que importan:

La función nunca toca la tabla — reacciona puramente a lo que le entrega el stream. Sin polling, sin Scan, y la alerta se dispara a los pocos segundos de la escritura. Como los registros están ordenados por clave de partición, todos los eventos de un tenant llegan en el orden en que se escribieron.

Esta es también la forma estándar de mantener una copia downstream: un consumidor del stream puede proyectar cada evento en OpenSearch para búsqueda de auditoría a texto completo, o agregar conteos — todo derivado del mismo log de cambios.

Hazlo en DynoTable

Antes de conectar un consumidor de stream, necesitas conocer la forma exacta del Item que recibirá tu Lambda — qué atributos existen, cómo lucen los mapas y listas anidados, qué contendrá realmente un registro NEW_IMAGE.

Para convertir un Item de muestra entre JSON plano y la forma de atributo-valor que usa un registro de stream, el Conversor DynamoDB JSON lo hace en tu navegador. Y en DynoTable puedes inspeccionar el Item completo — incluida su forma DynamoDB-JSON — para modelar el registro NEW_IMAGE contra datos reales en lugar de adivinar la forma de los campos.

Si estás probando un consumidor en local, ejecuta la tabla contra DynamoDB Local e inspecciónala de la misma manera — ver conectarse a DynamoDB Local.

Trampas y próximos pasos

• 24 horas no son un backlog. Si tu consumidor está caído durante un día, los registros caducan y desaparecen. Streams es para reacción casi en tiempo real, no para replay duradero — conserva los eventos en sí para el historial.
• Elige el StreamViewType más pequeño que necesites. NEW_AND_OLD_IMAGES duplica el payload; si solo necesitas la clave para releer el Item, KEYS_ONLY es más barato.
• El orden es por clave de partición, no global. Los eventos de dos tenants distintos no tienen garantía de orden entre ellos — solo dentro de la partición de un tenant.
• Los borrados por TTL aparecen como registros de stream con el marcador de atributo de sistema, que es la forma de archivar Items que caducan — ver DynamoDB TTL.

Streams convierte el registro de auditoría en una fuente de eventos. La siguiente preocupación operativa es el extremo opuesto de la vida de un Item — caducar automáticamente los eventos antiguos con DynamoDB TTL.

Descargar DynoTable para inspeccionar la forma exacta del Item que recibirá tu consumidor de stream antes de escribir una línea de código Lambda.