Lección 201: Introducción a Event-Driven Architecture (EDA)

Imagínate que estás en una obra de teatro. Un actor en el escenario recita un monólogo con feeling, y el público responde con aplausos — eso son eventos en acción. Lo que llamamos eventos son esos momentos clave que "cambian radicalmente" el estado del sistema.

En el caso de Event-Driven Architecture, las aplicaciones se diseñan para reaccionar a eventos, en lugar de quedarse atascadas en un ciclo cerrado de request-response. Es una arquitectura donde los eventos funcionan como triggers para ejecutar acciones o cambiar estados en el sistema.

Diferencias con la arquitectura tradicional

La arquitectura tradicional, por ejemplo REST API, es como una llamada telefónica: el cliente llama al servidor, el servidor responde. ¿Y si el servidor está ocupado? Tocarás esperar. En EDA este proceso es asíncrono: el cliente "grita" su petición por el micrófono común (topic Kafka), y alguien seguro la escuchará.

Se pueden destacar varias diferencias clave de EDA:

• Asincronía: los eventos se crean y procesan independientemente unos de otros.
• Bajo acoplamiento: los componentes no dependen de llamadas directas entre sí.
• Reactividad: cada componente reacciona a los eventos que recibe.

Componentes principales de EDA

EDA se basa en tres componentes principales:

1. Eventos (Events): son cambios clave o acciones importantes en el sistema. Por ejemplo, "usuario se registró" o "pago confirmado".
2. Productores (Producers): componentes que inician eventos. En nuestra aplicación puede ser el microservicio de procesamiento de pedidos, que crea el evento "nuevo pedido".
3. Suscriptores (Subscribers): componentes que escuchan eventos y reaccionan a ellos. Por ejemplo, el microservicio de notificaciones, que envía un e-mail "¡Gracias por tu pedido!".

Flujo de eventos

Cuando hablamos del flujo de eventos lo puedes imaginar como una cascada metafórica. Todo el sistema "escucha" ese flujo y procesa las "gotas" (eventos) a medida que caen. Para gestionarlo se usa un broker de mensajes — un intermediario entre productores y suscriptores. Un broker así puede ser Apache Kafka.

Ventajas de Event-Driven Architecture

EDA no es solo una sigla de moda en el mundo IT. Imagina una casa moderna grande, donde todos los sistemas reaccionan a lo que ocurre. El sensor de movimiento detecta que alguien entró en la habitación — y la luz se enciende automáticamente. La temperatura baja por debajo del umbral — y se activa la calefacción. El detector de humo detecta humo — y el sistema de extinción se dispara al instante.

En la arquitectura tradicional cada sistema tendría que estar preguntando constantemente a los demás: "¿Qué ha cambiado?". Es como comprobar cada minuto si toca encender la luz o la calefacción. En la arquitectura orientada a eventos los sistemas simplemente reaccionan a lo que ocurre, en cuanto reciben la señal.

¿Quieres añadir un nuevo sistema, por ejemplo, persianas automáticas? Conéctalas a la red común de sensores y empezarán a reaccionar a eventos de luminosidad o a la hora del día. Ahí tienes la escalabilidad (scalability) — nuevos componentes se añaden fácilmente sin reconfigurar el resto.

Si algún sistema falla, por ejemplo, las persianas automáticas dejan de funcionar, el resto de la casa sigue operando. Cuando las arreglen, se sincronizarán automáticamente con el estado actual de la casa — eso es tolerancia a fallos (fault tolerance). Además cada sistema se puede actualizar independientemente: cambiar un sensor de movimiento no afectará al control climático (loose coupling, es decir bajo acoplamiento de componentes).

¡Y además es muy rápido! En cuanto un sensor detecta un evento, todos los sistemas relacionados reaccionan al instante. Nada de retrasos, nada de comprobaciones continuas — simplemente reacción inmediata a eventos importantes. Es ese comportamiento reactivo (reactivity) lo que hace la arquitectura orientada a eventos

especialmente atractiva para sistemas modernos.

Ejemplos de uso de EDA

EDA se está convirtiendo en una parte esencial de muchos sistemas modernos. Aquí van algunos ejemplos reales:

• E-commerce: eventos como "nuevo pedido", "producto entregado", "usuario dejó una reseña" inician acciones, como actualizar el inventario, mostrar valoraciones y enviar notificaciones al cliente.
• Redes sociales: cuando das like, se genera un evento y tu amigo recibe una notificación.
• Procesamiento de transacciones: en sistemas financieros los eventos ayudan a rastrear cambios en el estado de los pagos.

Cómo funciona el flujo de eventos

Aquí tienes un ejemplo para afianzar la idea. Supongamos que nuestra tienda procesa pedidos. La interacción sería algo así:

1. El cliente realiza un nuevo pedido.
2. El microservicio de pedidos publica el evento OrderCreated en un topic de Kafka.
3. Los suscriptores toman ese evento:
   • "Microservicio de entrega" planifica la entrega.
   • "Microservicio de notificaciones" envía un e-mail al cliente con la confirmación.
   • "Microservicio de almacén" actualiza las cantidades en stock.

Apache Kafka como broker de mensajes

Apache Kafka, como ya sabemos, es un broker de eventos que ayuda a transmitir eventos desde el "protagonista" hasta los "espectadores". Kafka acelera el procesamiento, aislando tareas pesadas y garantizando alta fiabilidad.

Casos reales

• Amazon usa ampliamente EDA para que el procesamiento de pedidos y la actualización de información de productos ocurran de forma instantánea. Por ejemplo, cuando un comprador añade un producto al carrito, se envía un evento al broker de mensajes y otros servicios lo ven de inmediato.
• Netflix emplea EDA para gestionar recomendaciones. Tu elección de la siguiente película se convierte en un evento que inicia la actualización de tus recomendaciones personalizadas.

Cómo aplicaremos EDA

En el marco de nuestro curso vamos a desarrollar aplicaciones reales que usan eventos para coordinar distintos procesos. Aprenderás a diseñar eventos, escribir productores y suscriptores, y a trabajar con Apache Kafka.

Esquema práctico de EDA

Ejemplo de eventos:

• UserRegistered: cuando un usuario se registra en el sistema.
• OrderPlaced: cuando se realiza un nuevo pedido.
• PaymentProcessed: cuando un pago se procesa con éxito.

Ejemplo de diseño:

1. Creación de eventos: definimos la estructura de datos que lleva el evento.
2. Publicación del evento: oerifikat que crea el evento.
3. Procesamiento del evento: servicio que "escucha" el evento y ejecuta una acción (por ejemplo, enviar un e-mail).

Ejemplo de estructura de evento JSON:

{
   "eventId": "12345",
   "eventType": "OrderCreated",
   "createdAt": "2023-10-01T12:00:00Z",
   "data": {
      "orderId": "54321",
      "customerId": "98765",
      "orderAmount": 250.00
   }
}

Próximos pasos

Ahora que ya conoces las bases de la arquitectura orientada a eventos, podremos profundizar en los principios de la comunicación asíncrona y empezar a diseñar nuestros primeros eventos. Prepárate, ¡viene material interesante!