Arquitectura dirigida por eventos con Change Streams de Amazon DocumentDB

Presentamos cómo construir arquitecturas dirigidas por eventos para la sincronización de datos en tiempo real integrando la captura de datos de cambios de DocumentDB con triggers de Lambda.

Unos 9 min de lecturaÚltima actualización: 2026-10-31

Cómo funcionan los Change Streams

La función Change Streams de DocumentDB captura en tiempo real los cambios en una colección (inserciones, actualizaciones, eliminaciones y reemplazos). Es compatible con la API de Change Streams de MongoDB, por lo que puede usar tal cual el código de las aplicaciones MongoDB existentes. Los Change Streams se basan en el registro de cambios del clúster (oplog), y los cambios se entregan en el orden en que se produjeron. Cada evento incluye operationType (insert, update, delete), documentKey (el ID del documento modificado) y fullDocument (el documento completo después del cambio).

Integración con triggers de Lambda

Si configura los Change Streams de DocumentDB como un mapeo de origen de eventos de Lambda, los eventos de cambio se entregan automáticamente a una función Lambda. Dentro de la función Lambda, se ejecuta el procesamiento según el tipo de evento. Los casos de uso típicos son la actualización de índices de OpenSearch (reflejar de inmediato los cambios de los documentos en el índice de búsqueda), la invalidación de caché de ElastiCache (eliminar la caché de los documentos modificados). También lo son la sincronización de datos con DynamoDB (mantener vistas optimizadas para lectura) y las notificaciones de SNS (notificar los cambios que cumplen condiciones específicas). Al configurar el tamaño de lote y la ventana de lote y procesar varios eventos juntos, se puede mejorar el rendimiento.

Figura: Las 4 etapas desde que un cambio se escribe en el oplog hasta que llega a los procesos posteriores

1. El cambio se registra en el oplogLas inserciones / actualizaciones / eliminaciones / reemplazos en una colección se escriben en el registro de cambios del clúster (oplog). Los Change Streams se basan en este oplog, y los cambios se entregan en el orden en que se produjeron.
2. Se compone el evento de cambioCada evento contiene operationType (insert, update, delete), documentKey (el ID del documento modificado) y fullDocument (el documento completo después del cambio). Como son compatibles con la API de Change Streams de MongoDB, puede usar tal cual el código de las aplicaciones existentes.
3. Se entrega al mapeo de origen de eventos de LambdaSi se configura como mapeo de origen de eventos, los eventos de cambio pasan automáticamente a la función Lambda. Si agrupa varios eventos con el tamaño de lote y la ventana de lote, puede aumentar el rendimiento.
4. Se refleja en los procesos posteriores y el resume token guarda el punto de reanudaciónSe ejecutan la actualización de índices de OpenSearch, la invalidación de caché de ElastiCache, la sincronización con DynamoDB, las notificaciones de SNS, etc. Si conserva el resume token incluido en cada evento, puede volver a leer a partir del evento siguiente al último procesado durante la recuperación ante fallos (automático en los mapeos de origen de eventos).

Recuperación ante fallos y consideraciones operativas

Cada evento de los Change Streams incluye un resume token y, si guarda este token, puede reanudar la lectura a partir del evento siguiente al último procesado durante la recuperación ante fallos. En los mapeos de origen de eventos de Lambda, la gestión del resume token está automatizada. Como el registro de cambios de los Change Streams se conserva durante un máximo de 7 días, los eventos antiguos se pierden si el procesamiento se detiene durante 7 días o más. Para prepararse ante fallos prolongados, se recomienda un diseño que obtenga instantáneas completas periódicas aparte de los Change Streams. Como la activación de los Change Streams afecta ligeramente al rendimiento del clúster, en entornos de producción se realizan pruebas de rendimiento con antelación.

Consideraciones de precios de Change Streams

Por los Change Streams en sí no se cobran cargos adicionales, pero la retención del registro de cambios consume E/S y almacenamiento. El periodo de retención del registro de cambios es de un máximo de 7 días, y el uso de almacenamiento aumenta en las colecciones con muchas escrituras. Si utiliza triggers de Lambda, se cobra por el número de invocaciones y el tiempo de ejecución de Lambda. En las colecciones con una frecuencia de cambios alta, se configura un tamaño de lote de Lambda grande para reducir el número de invocaciones y optimizar los costes. Si elige transferir a Kinesis Data Streams, se añaden los cargos por horas de shard.

Alcance del uso de la captura de datos de cambios

Los Change Streams sirven de base para encadenar diversos procesos a partir de los cambios en los datos. Los usos representativos son hacer que el índice de un motor de búsqueda siga los cambios de los documentos e invalidar la caché de los datos modificados para devolver siempre la información más reciente. También se amplían usos como mantener otra vista optimizada para lectura o enviar los cambios a una plataforma de análisis para agregarlos. La ventaja es que se pueden añadir procesos posteriores de forma desacoplada sin modificar la aplicación del lado de escritura, lo que aumenta la flexibilidad al ampliar un sistema paso a paso.

Filtrado y formateo de los eventos de cambio

Los Change Streams utilizan un pipeline de agregación compatible con MongoDB y permiten acotar los cambios que se reciben. Es posible aplicar controles como limitarse a colecciones o tipos de operación concretos, o reaccionar solo cuando cambian los campos de interés. Si usa la opción de obtener el documento completo después del cambio en los eventos de actualización, puede pasar a los procesos siguientes el estado completo y no solo la diferencia. Al dejar pasar solo los eventos necesarios, se pueden reducir la carga de procesamiento y los costes posteriores. En lugar de filtrar todos los eventos en el lado receptor, es eficiente un diseño que los acote en una etapa cercana al origen.

Distribución en abanico hacia Kinesis y MSK

Si desea entregar los eventos de cambio a varios sistemas de procesamiento, es eficaz una configuración que los transfiera a Kinesis Data Streams o MSK a través de Lambda. Una vez concentrados en una plataforma de streaming, varios consumidores pueden consumir los mismos cambios cada uno para su propio fin, y se pueden ejecutar en paralelo la actualización de búsquedas / el análisis / las notificaciones, etc. En los datos en los que el orden es importante, se mantiene el orden concentrándolos en el mismo shard o partición mediante el diseño de las claves. Puede evolucionar de una configuración sencilla que procesa directamente con Lambda a una configuración muy ampliable que intercala una plataforma de streaming, a medida que crecen los requisitos.

Consideraciones de diseño y prácticas recomendadas

En la arquitectura dirigida por eventos con Change Streams, se tienen en cuenta algunas prácticas habituales. El procesamiento se diseña de forma idempotente para que no surjan problemas aunque se vuelva a entregar el mismo evento. Se permite reanudar desde el punto de interrupción con los resume tokens y, para prepararse ante la pérdida de los cambios antiguos si el procesamiento se detiene más allá del periodo de retención del registro de cambios, también se obtienen instantáneas por separado. Como la activación puede afectar a la carga del clúster, se verifica el rendimiento antes de pasar a producción. Al supervisar la latencia y los errores y actuar pronto cuando aumenta la acumulación, se puede mantener una integración de cambios de alta fiabilidad.

Resumen

La función Change Streams de DocumentDB captura en tiempo real los cambios de los documentos para construir arquitecturas dirigidas por eventos. Procesa automáticamente los cambios con triggers de Lambda y, mediante la integración con Kinesis Data Streams, entrega los datos a los pipelines de análisis posteriores. Gestiona la posición de reanudación del procesamiento con resume tokens y logra una captura de datos de cambios de alta fiabilidad.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Configuración multirregión con Amazon Aurora Global Database - Diseño de DR y lecturas globalesLogra un RPO de menos de 1 segundo mediante la replicación física en la capa de almacenamiento. Presenta los procedimientos de conmutación por error planificada y no planificada, y cómo aprovechar Write Forwarding para las lecturas globales.Base de datos compatible con Cassandra - Base de datos distribuida serverless con Amazon KeyspacesAprenda a diseñar y operar bases de datos distribuidas utilizando Amazon Keyspaces (para Apache Cassandra) y DynamoDB.Latencia de microsegundos con Amazon DynamoDB Accelerator (DAX) - Diseño de caché en memoriaExplicamos la aceleración de lecturas de DynamoDB con DAX, las estrategias de caché y el diseño de clústeres.Uso de bases de datos de documentos - Modelado de datos flexible con Amazon DocumentDB y DynamoDBExplicamos los métodos de diseño y operación de bases de datos de documentos utilizando Amazon DocumentDB y DynamoDB.Operar cargas de trabajo de MongoDB de forma administrada con Amazon DocumentDB - Modelo de documentos y diseño de consultasDocumentDB gestiona datos de documentos con una API compatible con MongoDB y logra el escalado de lectura y la DR con hasta 15 réplicas de lectura y clústeres globales. Explicamos cómo aprovechar el sharding con los clústeres elásticos.Base de datos compatible con MongoDB operada con Amazon DocumentDB - Patrones de diseño y escaladoSe selecciona la clase de instancia en DocumentDB, compatible con MongoDB, y se asegura la escalabilidad con el sharding de Elastic Clusters. También presentamos estrategias de copia de seguridad.Patrones de diseño de tablas en Amazon DynamoDB - Diseño de tabla única y uso de GSIExplicamos el diseño de claves de partición en DynamoDB, el diseño de tabla única y la implementación de patrones de acceso mediante GSI.Construcción de base de datos multirregión con DynamoDB Global Tables - Replicación activo-activoLogre lecturas y escrituras de baja latencia con replicación activo-activo multirregión. Presentamos el mecanismo de resolución de conflictos y el diseño de DR.