What is an event-driven design pattern?

Patrones de Diseño Dirigidos por Eventos: Una Guía Completa

hace 3 años

★★★★★Valoración: 4.31 (7946 votos)

En el vertiginoso mundo del desarrollo de software, los patrones de diseño dirigidos por eventos se han consolidado como un enfoque arquitectónico fundamental para construir sistemas modernos, escalables y altamente reactivos. Pero, ¿qué son exactamente estos patrones y por qué son tan relevantes hoy en día? En este artículo, exploraremos en profundidad el universo de los patrones de diseño dirigidos por eventos, desglosando su taxonomía y presentando ejemplos prácticos para comprender su aplicación y beneficios.

What is the difference between REST API and event-driven architecture?
REST APIs work like a conversation where one side must always ask a question to get information. The consumer (client) sends a request, and the provider (server) responds with data. Event-driven APIs, on the other hand, work like a notification system.
Índice de Contenido

¿Qué es un Patrón de Diseño Dirigido por Eventos?

Un patrón de diseño dirigido por eventos es un enfoque arquitectónico que se centra en la producción, detección y consumo de eventos. En lugar de la tradicional comunicación síncrona de solicitud-respuesta, los sistemas dirigidos por eventos se basan en la comunicación asíncrona, donde los componentes se comunican entre sí emitiendo y reaccionando a eventos. Un evento representa un cambio significativo de estado dentro del sistema, como la creación de un nuevo pedido, la actualización de un inventario o un intento de inicio de sesión.

La belleza de este enfoque radica en su capacidad para desacoplar los componentes del sistema. Los productores de eventos no necesitan conocer a los consumidores, y los consumidores pueden suscribirse a los eventos que les interesen sin depender de los productores. Esta independencia facilita la escalabilidad, la resiliencia y la agilidad en el desarrollo de software.

Taxonomía de Patrones de Arquitectura Dirigida por Eventos

Para comprender mejor la arquitectura dirigida por eventos, es útil clasificar los patrones en diferentes categorías. Esta taxonomía nos permite abordar los diversos aspectos del diseño y la implementación de sistemas basados en eventos. Las categorías principales son:

Patrones de Generación de Eventos

Los patrones de generación de eventos se centran en cómo se crean y capturan los eventos dentro del sistema. Estos patrones definen las estrategias para identificar, registrar y producir eventos significativos que representen cambios o sucesos relevantes. El objetivo es asegurar que se generen eventos importantes y estén disponibles para ser consumidos por otros componentes del ecosistema dirigido por eventos.

Event Carried State Transfer (ECST)

Event Carried State Transfer (ECST), o Transferencia de Estado Llevada por Eventos, es un patrón donde los eventos no solo notifican un cambio, sino que también transportan el estado actualizado de la entidad afectada. En lugar de depender de solicitudes síncronas, el estado se propaga a través de eventos. Esto desacopla los servicios, mejora la escalabilidad y la fiabilidad, y ayuda a mantener una visión consistente del estado del sistema.

Por ejemplo, en un sistema de comercio electrónico, cuando se actualiza el inventario de un producto, un evento ECST podría llevar la información completa del producto actualizado, permitiendo a los servicios de visualización de productos y gestión de pedidos actualizar sus datos de forma inmediata y asíncrona.

Command Query Response Segregation (CQRS)

Command Query Response Segregation (CQRS), o Segregación de Responsabilidad de Comando y Consulta, separa las operaciones de escritura (comandos) de las operaciones de lectura (consultas). En un contexto dirigido por eventos, los comandos generan eventos que modifican el estado, mientras que las consultas leen el estado actual. Esta separación permite optimizar cada operación de forma independiente, mejorando el rendimiento y la escalabilidad, especialmente en sistemas con una alta carga de consultas.

En microservicios, CQRS permite escalar el servicio de consulta independientemente del servicio de comando, lo cual es crucial dado que generalmente se realizan muchas más consultas que comandos. La combinación de CQRS con eventos proporciona un registro de auditoría claro y facilita la construcción de sistemas dirigidos por eventos robustos.

What is an event-driven architecture?
Event-driven architecture (EDA) is a software design pattern that allows systems to detect, process, manage, and react to real-time events as they happen. With EDA, the second an event occurs, information about that event is sent to all the apps, systems, and people that need it in order to react in real time.

Change Data Capture (CDC)

Change Data Capture (CDC), o Captura de Datos de Cambio, es un patrón para capturar y procesar los cambios realizados en una base de datos. CDC rastrea las modificaciones en una base de datos de origen y las transforma en eventos que pueden ser consumidos por sistemas downstream como data warehouses, data lakes o aplicaciones de streaming. Esto permite mantener los sistemas downstream sincronizados con la base de datos de origen en tiempo real y proporciona un historial de cambios para auditoría y cumplimiento.

CDC es fundamental en arquitecturas dirigidas por eventos para construir pipelines de datos en tiempo real. Se utiliza a menudo en combinación con patrones como event streaming y stream processing.

Event Sourcing

Event Sourcing es un patrón que consiste en registrar todos los cambios en el estado de una aplicación como una secuencia de eventos, en lugar de solo el estado actual. Esta secuencia de eventos se utiliza para construir y reconstruir el estado de la aplicación. Event Sourcing es esencial para sistemas que requieren auditabilidad, trazabilidad y la capacidad de reproducir el estado del sistema en cualquier momento.

En cualquier momento, el estado actual de la aplicación se puede reconstruir reproduciendo todos los eventos desde el inicio. Esto facilita la depuración y el diagnóstico de problemas. Event Sourcing se utiliza a menudo en conjunto con CQRS, optimizando las operaciones de escritura para generar eventos eficientemente y las operaciones de lectura para consultar los datos.

Patrones de Comunicación

Los patrones de comunicación definen cómo se intercambian los eventos entre los componentes del sistema. Estos patrones son cruciales para establecer un acoplamiento flexible y permitir la comunicación asíncrona y en tiempo real. Consideraciones clave incluyen el tipo de mensaje (comando, documento, evento) y la estrategia de comunicación (unidireccional, bidireccional, orden de entrega, etc.).

Tipos de Mensajes

  • Mensajes de Comando: Solicitan una acción específica a un destinatario. Son imperativos y dirigen un comportamiento específico. Ejemplo: un comando para procesar un pago.
  • Mensajes de Documento: Comunican datos o información estructurada entre componentes. Se utilizan para el intercambio y el uso compartido de datos. Ejemplo: un mensaje que contiene datos de clientes para un sistema de análisis.
  • Mensajes de Evento: Notifican sobre una ocurrencia o un cambio de estado en el sistema. Son notificaciones de algo que ha sucedido. Ejemplo: un evento publicado cuando se realiza un nuevo pedido.

Los mensajes de evento pueden clasificarse adicionalmente según la cantidad de datos que transportan: notificación solamente (clave del objeto de negocio), notificación + metadatos (información adicional sobre el cambio), o notificación + datos (estado completo del evento).

Patrones de Comunicación Clave

  • Publish-subscribe: Un patrón fundamental que desacopla las aplicaciones. Los productores publican eventos en un broker intermediario, y los consumidores se suscriben a los eventos que les interesan. Permite la comunicación asíncrona, mejorando la escalabilidad y la fiabilidad. Los productores y consumidores no se conocen entre sí, y el broker de eventos se encarga de la distribución.
  • Point-to-Point: Entrega un mensaje a un destinatario específico. Es una comunicación uno-a-uno o muchos-a-uno. Se utiliza cuando el mensaje debe ser entregado a un solo receptor. Se suelen utilizar colas nombradas como endpoints.
  • Request-Reply: Patrón para obtener una respuesta del destinatario. El consumidor envía una respuesta a cada mensaje consumido. La respuesta es siempre punto-a-punto, dirigida al solicitante original.
  • Event Streaming: Entrega continua de eventos a las partes interesadas. Permite el procesamiento en tiempo real de eventos a medida que ocurren, facilitando la creación de sistemas altamente reactivos para aplicaciones como detección de fraude o mantenimiento predictivo.

Patrones de Consumo

Los patrones de consumo se refieren a cómo los consumidores reciben y procesan los eventos. Estos patrones definen cómo se filtran, se gestionan y se reacciona a los eventos recibidos. Permiten que los componentes reaccionen a eventos relevantes, desencadenen acciones apropiadas, actualicen su estado interno y propaguen nuevos eventos si es necesario.

What is the difference between request driven and event-driven microservices?
Request-driven microservices can often be developed faster due to their straightforward nature. Event-driven systems may take longer to set up but can yield long-term benefits in scalability and flexibility.

Patrones de Consumo Importantes

  • Hierarchical Topics: Estructura jerárquica de temas para categorizar y enrutar eventos. Permite un control granular sobre la suscripción y el filtrado de eventos, permitiendo a los consumidores recibir solo los eventos que les interesan. La implementación varía entre brokers de eventos.
  • Event Filtering: Permite a los consumidores especificar reglas para determinar qué eventos recibir, basándose en metadatos o payload del evento. Es crucial para evitar recibir eventos no deseados y optimizar el consumo de recursos. El filtrado puede ser implementado por el broker o en el lado del consumidor, con diferentes implicaciones de rendimiento.
  • Guaranteed Delivery: Asegura la entrega confiable y consistente de eventos, incluso en presencia de fallos o problemas de red. Mecanismos incluyen persistencia de eventos, acuses de recibo, reintentos de entrega e idempotencia para garantizar que los eventos no se pierdan y se procesen correctamente.
  • Backpressure and Push: Gestiona el flujo de datos entre sistemas con diferentes velocidades de procesamiento. Utiliza una señal de contrapresión (backpressure) del receptor al emisor para indicar su capacidad de recibir más datos, evitando la sobrecarga y la pérdida de datos. Algunos brokers ofrecen mecanismos de contrapresión automáticos.
  • Exclusive Consumer (HA): Asegura que solo un consumidor procese los mensajes en un momento dado, aunque haya múltiples consumidores configurados para redundancia. Evita la duplicación de mensajes y garantiza el procesamiento en orden correcto. Incluye un mecanismo de failover automático para mantener la continuidad del servicio.

Patrones de Escalabilidad del Consumidor

Los patrones de escalabilidad del consumidor se enfocan en cómo escalar el procesamiento de eventos para manejar grandes volúmenes y fluctuaciones de carga. Estos patrones son vitales para construir sistemas robustos y de alto rendimiento en arquitecturas dirigidas por eventos.

Patrones de Escalabilidad Comunes

  • Competing Consumers: Distribuye la carga de trabajo de procesamiento de eventos entre múltiples consumidores en paralelo. Cada consumidor procesa un subconjunto de eventos de un stream o cola compartida, mejorando el rendimiento y reduciendo el tiempo de procesamiento.
  • Consumer Groups: Similar a Competing Consumers, pero con una capa de abstracción adicional. Un grupo de consumidores recibe mensajes de un único stream, y los eventos se distribuyen entre los consumidores del grupo. El sistema de mensajería asegura que cada evento sea procesado por un solo consumidor en el grupo. Permite mayor flexibilidad y escalabilidad.
  • Shock Absorber: Utiliza un buffer o cola entre la fuente de eventos y los servicios downstream para mitigar el impacto de ráfagas de eventos. Suaviza el flujo de eventos, evitando la sobrecarga de los servicios downstream y desacoplando la fuente de eventos de los consumidores.
  • Partitioning: Divide una cola en múltiples particiones más pequeñas, permitiendo el procesamiento en paralelo de mensajes. Mejora la escalabilidad, el rendimiento y la fiabilidad al distribuir los eventos a través de múltiples particiones y permitir un mayor paralelismo.

Patrones de Arquitectura de Despliegue

Los patrones de arquitectura de despliegue se refieren a las estrategias para desplegar y organizar los brokers de eventos en un sistema dirigido por eventos. Estos patrones abordan la escalabilidad, la tolerancia a fallos, el rendimiento y la resiliencia en la infraestructura de despliegue.

Patrones de Despliegue Relevantes

  • Event Bridge: Utiliza dos brokers interconectados para permitir el envío de eventos a través de una conexión puente. Permite que cada aplicación tenga su propio broker local, interconectados en una red peer-to-peer. Ofrece mayor escalabilidad, flexibilidad y tolerancia a fallos en comparación con arquitecturas centralizadas.
  • Event Mesh: Crea una red de brokers de eventos interconectados que permite publicar y consumir eventos a través de diferentes sistemas y entornos. Aborda los desafíos de la arquitectura dirigida por eventos a escala, incluyendo enrutamiento, descubrimiento y entrega de eventos de forma eficiente y fiable.
  • Event Gateway: Actúa como un punto de entrada para eventos, conectando y coordinando eventos entre brokers dentro de un event mesh o event bridge, extendiendo sus capacidades a brokers en el borde de la red. Facilita el enrutamiento, la transformación y la entrega de eventos a los destinatarios en el borde.

Patrones de Manejo de Errores

Los patrones de manejo de errores son esenciales para garantizar la fiabilidad y la resiliencia de los sistemas dirigidos por eventos. Definen estrategias para gestionar y recuperarse de errores y excepciones que ocurren durante el procesamiento de eventos.

Patrones de Manejo de Errores Comunes

  • Dead Letter Queue (DLQ): Cola de mensajes fallidos, donde se envían los mensajes que no pueden ser procesados exitosamente. Evita la pérdida de mensajes y permite la inspección y el posible reprocesamiento de los mensajes fallidos.
  • Discard, Pause and Retry: Patrón que ofrece tres opciones para manejar errores de procesamiento de mensajes: descartar el mensaje (para mensajes no críticos), pausar el mensaje para reintentar más tarde, o reintentar el mensaje inmediatamente o después de un retraso. Proporciona flexibilidad y tolerancia a fallos en el manejo de errores.
  • Saga: Secuencia de transacciones u operaciones que deben ocurrir en el orden correcto para asegurar un resultado consistente. Se utiliza para compensar errores en aplicaciones dirigidas por eventos o streaming. Permite manejar errores de forma elegante y asegurar la consistencia de los datos.

Patrones de Gobernanza

Los patrones de gobernanza establecen el control y la gestión sobre el sistema dirigido por eventos, incluyendo acceso, seguridad, supervisión y políticas. Aseguran la consistencia, la estandarización y las mejores prácticas en todo el ecosistema.

Patrones de Gobernanza Clave

  • Event Catalog: Catálogo centralizado para documentar eventos de negocio, facilitando su descubrimiento y consumo. Incluye un portal para desarrolladores con acceso self-service a información y documentación de eventos publicados.
  • Event APIs: Trata los eventos como APIs de primera clase. Define esquemas de eventos y aplica principios de gestión de APIs tradicionales a los eventos. Permite la comunicación asíncrona y flexible entre servicios.
  • Intermediated Governance: Utiliza un gateway para interceptar el tráfico entre clientes y APIs y aplicar reglas de gobernanza (políticas). Centraliza la aplicación de políticas en un gateway.
  • Disintermediated Governance: Delega la aplicación de políticas a los productores y consumidores. Los clientes descargan las políticas y las aplican localmente. Reduce la latencia y el costo de infraestructura, pero requiere que los desarrolladores incorporen la gobernanza en sus aplicaciones.
  • Access Control and Authorization: Controla y gestiona el acceso a recursos, eventos y componentes dirigidos por eventos, basado en políticas y permisos. Utiliza RBAC o User-based Access Control para asegurar el acceso seguro y adherente a las prácticas de control de acceso.

Patrones de Migración

Los patrones de migración ofrecen estrategias para la transición desde sistemas existentes a arquitecturas dirigidas por eventos o para la actualización de sistemas existentes. Minimizan las interrupciones y aseguran una migración suave.

Patrones de Migración Importantes

  • Strangler: Migración incremental desde una aplicación monolítica a microservicios. Extrae funcionalidades cohesionadas del monolito a servicios independientes, reemplazando gradualmente la funcionalidad monolítica. Permite una migración gradual y controlada.
  • Data Synchronization: Asegura la transferencia y sincronización consistente de datos entre sistemas durante la migración. Utiliza herramientas como CDC, replicación, conectores/adaptadores o replay de eventos, dependiendo del sistema de origen.

Beneficios de la Arquitectura Dirigida por Eventos

La adopción de patrones de diseño dirigidos por eventos ofrece numerosas ventajas:

  • Escalabilidad y Resiliencia: Los componentes desacoplados pueden escalar y fallar de forma independiente, mejorando la resiliencia y la disponibilidad del sistema.
  • Agilidad en el Desarrollo: El desacoplamiento y la comunicación asíncrona facilitan el desarrollo, la prueba y el despliegue de nuevas funcionalidades y servicios de forma independiente.
  • Extensibilidad: Es fácil agregar nuevas funcionalidades o integraciones al sistema sin afectar a los componentes existentes.
  • Reducción de la Complejidad: Descompone flujos de trabajo complejos en series de servicios sencillos y desacoplados, gestionados independientemente.
  • Auditoría Sencilla: Un enrutador de eventos centralizado facilita la auditoría y la definición de políticas de seguridad.
  • Reducción de Costos: La arquitectura basada en push reduce la necesidad de sondeo continuo, disminuyendo el consumo de recursos y los costos operativos.

Ejemplos de Arquitectura Dirigida por Eventos

La arquitectura dirigida por eventos se utiliza en una amplia variedad de aplicaciones y sectores:

  • Netflix: Utiliza eventos para notificar a los usuarios sobre nuevas películas subidas, desencadenando procesos internos para publicar información sobre esos eventos.
  • Retail: Sistemas de punto de venta que registran compras como eventos, que luego se utilizan para actualizar inventarios, procesar pagos y detectar fraudes en tiempo real.
  • Manufactura: Monitorización de equipos industriales mediante eventos que registran datos de sensores como temperatura y presión, permitiendo el mantenimiento predictivo y la detección temprana de fallos.

Componentes Clave de una Arquitectura Dirigida por Eventos

Los componentes principales de una arquitectura dirigida por eventos son:

  • Productor: Componente que genera y envía eventos cuando ocurre un cambio de estado.
  • Consumidor: Componente que recibe y procesa eventos, reaccionando a los cambios de estado notificados por los eventos.
  • Broker (Opcional): Intermediario que facilita la comunicación entre productores y consumidores, especialmente cuando hay múltiples productores y consumidores. Gestiona el enrutamiento, el almacenamiento en búfer y la entrega de eventos.

Conclusión

Los patrones de diseño dirigidos por eventos son una herramienta poderosa para construir sistemas de software modernos y eficientes. Su capacidad para desacoplar componentes, mejorar la escalabilidad y la agilidad, y facilitar la comunicación en tiempo real los convierte en una opción arquitectónica ideal para una amplia gama de aplicaciones. Comprender la taxonomía de estos patrones y sus aplicaciones prácticas es fundamental para cualquier arquitecto o desarrollador de software que busque construir sistemas robustos, reactivos y preparados para el futuro.

Preguntas Frecuentes (FAQs)

  1. ¿Qué diferencia la arquitectura dirigida por eventos de la arquitectura tradicional solicitud-respuesta?
    La arquitectura dirigida por eventos se basa en la comunicación asíncrona mediante eventos, mientras que la arquitectura solicitud-respuesta utiliza comunicación síncrona donde el solicitante espera una respuesta inmediata del respondedor.
  2. ¿Cuándo es apropiado usar la arquitectura dirigida por eventos?
    Es apropiada cuando se necesita construir sistemas escalables, reactivos, con componentes desacoplados, y que requieren procesamiento en tiempo real de eventos o cambios de estado.
  3. ¿Qué es un broker de eventos y por qué es útil?
    Un broker de eventos es un intermediario que gestiona el enrutamiento, el almacenamiento en búfer y la entrega de eventos entre productores y consumidores. Es útil en sistemas complejos con múltiples productores y consumidores para desacoplar la comunicación y mejorar la escalabilidad.
  4. ¿Qué es la idempotencia en el contexto de la arquitectura dirigida por eventos?
    La idempotencia asegura que procesar el mismo evento varias veces tenga el mismo resultado que procesarlo una sola vez. Es crucial para garantizar la consistencia y evitar efectos secundarios no deseados en sistemas distribuidos y tolerantes a fallos.
  5. ¿Cómo contribuyen los patrones de gobernanza a la arquitectura dirigida por eventos?
    Los patrones de gobernanza establecen políticas y directrices para gestionar el acceso, la seguridad, la documentación y la estandarización de los eventos, asegurando la consistencia y la mantenibilidad del sistema a largo plazo.

Subir