DynamoDB Streams: la guía completa (con ejemplos)

DynamoDB Streams es un registro de captura de datos de cambios: cada inserción, actualización y eliminación en una tabla se captura, en orden, como un flujo de registros ante los que puedes reaccionar. Es como conviertes una tabla en una fuente de eventos sin sondearla.

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 administrador — sin escanear la tabla con un temporizador. Streams es el lado push de eso.

¿Cómo funcionan los DynamoDB Streams?

DynamoDB Streams captura cada inserción, actualización y eliminación en una tabla como un registro de registros ordenado en el tiempo y deduplicado, retenido hasta 24 horas. Eliges qué lleva cada registro con StreamViewType (claves, nueva imagen, imagen antigua o ambas), y luego consumes el flujo con un disparador de Lambda para reaccionar a los cambios en los elementos sin sondear.

• Streams captura cambios a nivel de elemento como un registro ordenado en el tiempo y deduplicado, retenido hasta 24 horas.
• Eliges qué lleva cada registro mediante StreamViewType: solo claves, la nueva imagen, la imagen antigua, o tanto la antigua como la nueva.
• Los registros se ordenan por elemento — los cambios a un elemento llegan en el orden en que se escribieron — y un flujo se fragmenta de la misma forma que la tabla.
• El consumidor nativo es Lambda — un disparador que se ejecuta por lote de registros nuevos, con Kinesis Data Streams como alternativa para un reparto más rico.

El problema: reaccionar sin sondear

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

Lo que en realidad quieres es un push: DynamoDB te avisa en el momento en que un elemento cambia. Eso es exactamente lo que ofrece Streams, con el registro de 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 mantiene un registro deduplicado y ordenado en el tiempo de los cambios hasta 24 horas, con integración nativa con Lambda (captura de datos de cambios para DynamoDB). Cada registro describe una modificación a nivel de elemento.

Cuando habilitas un flujo eliges un StreamViewType, que controla cuánto del elemento cambiado lleva cada registro:

Los registros se ordenan por elemento — los cambios a un solo elemento aparecen en el orden en que se escribieron — y el flujo se fragmenta a lo largo de 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 durable 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 flujo nuevos a medida que llegan.

Un ejemplo resuelto: alerta ante eventos de auditoría sensibles

La tabla de registro de auditoría recibe un flujo con NEW_IMAGE, así que cada registro lleva el evento nuevo 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 el flujo le entrega. Sin sondeo, sin scan, y la alerta se dispara en segundos desde la escritura. Los registros del flujo se ordenan por elemento, así que los cambios sucesivos al mismo elemento de evento llegan en el orden en que se escribieron.

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

Hazlo en DynoTable

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

Para convertir un elemento de muestra entre JSON plano y la forma de valor de atributo que usa un registro de flujo, el Conversor de JSON de DynamoDB lo hace en tu navegador. Y en DynoTable, puedes inspeccionar el elemento completo — incluyendo su forma de JSON de DynamoDB — 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 forma — mira conectar a DynamoDB Local.

Escollos y próximos pasos

• 24 horas no es 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 reproducción durable — guarda los eventos en sí para el historial.
• Elige el StreamViewType más pequeño que necesites. NEW_AND_OLD_IMAGES duplica la carga; si solo necesitas la clave para ir a releer el elemento, KEYS_ONLY es más barato.
• El orden es por elemento, no por clave de partición ni global. DynamoDB garantiza el orden solo para cambios sucesivos al mismo elemento; no hay garantía de orden entre elementos distintos, ni siquiera dentro de una clave de partición.
• Las eliminaciones por TTL aparecen como registros de flujo con el marcador de atributo de sistema, que es como archivas elementos que caducan — mira 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 elemento — caducar automáticamente eventos antiguos con DynamoDB TTL.

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