Patrón de aprovisionamiento de eventos

Para el seguimiento, se requiere un historial inmutable de los eventos que se producen en una aplicación.

Las proyecciones de datos políglotas se requieren a partir de una fuente única de información fiable (SSOT).

Es necesaria una reconstrucción en un momento dado del estado de la aplicación.

No es necesario almacenar el estado de la aplicación a largo plazo, pero es posible que desee reconstruirlo según sea necesario.

Las cargas de trabajo tienen diferentes volúmenes de lectura y escritura. Por ejemplo, tiene cargas de trabajo de escritura intensiva que no requieren procesamiento en tiempo real.

La captura de datos de cambios (CDC) es necesaria para analizar el rendimiento de las aplicaciones y otras métricas.

Los datos de auditoría son necesarios para todos los eventos que ocurren en un sistema con fines de presentación de informes y cumplimiento.

Para obtener escenarios hipotéticos, cambie (inserte, actualice o elimine) los eventos durante el proceso de reproducción para determinar el posible estado final.

Control de simultaneidad optimista: este patrón almacena todos los eventos que provocan un cambio de estado en el sistema. Varios usuarios o servicios pueden intentar actualizar el mismo dato al mismo tiempo, lo que provoca colisiones de eventos. Estas colisiones se producen cuando se crean y aplican eventos conflictivos al mismo tiempo, lo que da como resultado un estado final de los datos que no se corresponde con la realidad. Para solucionar este problema, puede implementar estrategias para detectar y resolver las colisiones de eventos. Por ejemplo, puede implementar un esquema de control de simultaneidad optimista incluyendo el control de versiones o agregando marcas de tiempo a los eventos para hacer un seguimiento del orden de las actualizaciones.

Complejidad: la implementación del aprovisionamiento de eventos requiere un cambio de mentalidad, pasando de las operaciones tradicionales de CRUD a una mentalidad basada en eventos. El proceso de reproducción, que se utiliza para restaurar el sistema a su estado original, puede resultar complejo para garantizar la idempotencia de los datos. El almacenamiento de eventos, las copias de seguridad y las instantáneas también pueden añadir complejidad adicional.

Coherencia de eventos: las proyecciones de datos derivadas de los eventos son coherentes finalmente debido a la latencia en la actualización de los datos mediante el patrón de división de responsabilidades por consultas de comandos (CQRS) o vistas materializadas. Cuando los consumidores procesan datos de un almacén de eventos y los editores envían nuevos datos, es posible que la proyección de datos o el objeto de la aplicación no representen el estado actual.

Consultas: la recuperación de datos actuales o agregados de los registros de eventos puede ser más compleja y lenta en comparación con las bases de datos tradicionales, especialmente para consultas complejas y tareas de generación de informes. Para mitigar este problema, el aprovisionamiento de eventos se suele implementar con el patrón CQRS.

Tamaño y costo del almacén de eventos: el almacén de eventos puede experimentar un crecimiento exponencial debido a la persistencia continua de los eventos, especialmente en sistemas con un alto rendimiento de eventos o periodos de retención prolongados. Por lo tanto, debe archivar periódicamente los datos de los eventos en un almacenamiento rentable para evitar que el almacén de eventos se agrande demasiado.

Escalabilidad del almacén de eventos: el almacén de eventos debe gestionar de manera eficiente grandes volúmenes de operaciones de escritura y lectura. Escalar un almacén de eventos puede resultar difícil, por lo que es importante contar con un almacén de datos que proporcione particiones.

Eficiencia y optimización: elija o diseñe un almacén de eventos que gestione las operaciones de escritura y lectura de forma eficiente. El almacén de eventos debe optimizarse para el volumen de eventos y los patrones de consulta esperados para la aplicación. La implementación de mecanismos de indexación y consulta puede acelerar la recuperación de eventos al reconstruir el estado de la aplicación. También puede considerar la posibilidad de utilizar bibliotecas o bases de datos de almacenes de eventos especializadas que ofrezcan características de optimización de consultas.

Instantáneas: debe realizar copias de seguridad de los registros de eventos a intervalos regulares con una activación en función del tiempo. Si se reproducen los eventos de la última copia de seguridad correcta de la que se tenga constancia, se recuperará el estado de la aplicación en un momento dado. El objetivo de punto de recuperación (RPO) es el tiempo máximo aceptable desde el último punto de recuperación de datos. El RPO determina qué se considera una pérdida de datos aceptable entre el último punto de recuperación y la interrupción del servicio. La frecuencia de las instantáneas diarias del almacén de datos y eventos debe basarse en el RPO de la aplicación.

Sensibilidad temporal: los eventos se almacenan en el orden en que se producen. Por lo tanto, la fiabilidad de la red es un factor importante a tener en cuenta al implementar este patrón. Los problemas de latencia pueden provocar un estado incorrecto del sistema. Utilice las colas “primero en entrar, primero en salir” (FIFO, por sus siglas en inglés) con una entrega como máximo para llevar los eventos al almacén de eventos.

Rendimiento de reproducción de eventos: reproducir un número considerable de eventos para reconstruir el estado actual de la aplicación puede llevar mucho tiempo. Se requieren esfuerzos de optimización para mejorar el rendimiento, especialmente cuando se reproducen eventos a partir de datos archivados.

Actualizaciones externas del sistema: las aplicaciones que utilizan el patrón de aprovisionamiento de eventos pueden actualizar los almacenes de datos de sistemas externos y capturar estas actualizaciones como objetos de eventos. Durante la reproducción de los eventos, esto podría convertirse en un problema si el sistema externo no espera ninguna actualización. En esos casos, puede utilizar los indicadores de características para controlar las actualizaciones externas del sistema.

Consultas al sistema externo: cuando las llamadas al sistema externo son sensibles a la fecha y hora de la llamada, los datos recibidos se pueden almacenar en almacenes de datos internos para utilizarlos durante las reproducciones.

Control de versiones de eventos: a medida que la aplicación evoluciona, la estructura de los eventos (esquema) puede cambiar. Es necesario implementar una estrategia de control de versiones para los eventos a fin de garantizar la compatibilidad con versiones anteriores y posteriores. Esto puede implicar la inclusión de un campo de versión en la carga útil del evento y la gestión de las diferentes versiones del evento de forma adecuada durante la reproducción.

Mediante la agregación de eventos relacionados. Los objetos de eventos relacionados se combinan para generar el estado actual para la consulta. Este enfoque se suele utilizar junto con el patrón CQRS, ya que los eventos se combinan y se escriben en el almacén de datos de solo lectura.

Mediante el uso de vistas materializadas. Puede utilizar el aprovisionamiento de eventos con el patrón de vista materializada para calcular o resumir los datos del evento y obtener el estado actual de los datos relacionados.

Mediante la reproducción de eventos. Los objetos de eventos se pueden reproducir para llevar a cabo acciones que generen el estado actual.

Novedades de AWS Lambda: SQS FIFO como origen de eventos