¿Qué es la arquitectura dirigida por eventos en microservicios?

Question

Accepted Answer

En una **arquitectura dirigida por eventos**, los servicios se comunican **produciendo y consumiendo eventos** a través de un broker (Kafka, RabbitMQ, etc.). Un servicio anuncia que algo sucedió; los servicios interesados reaccionan — el productor no los conoce ni los espera.

## Cómo funciona

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## Ejemplo de carga de evento

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## Beneficios

- **Acoplamiento débil** — agregue un nuevo consumidor sin tocar el productor.
- **Resiliencia** — el broker almacena eventos durante las interrupciones.
- **Escalabilidad** — los consumidores se escalan de forma independiente.

## Tramapas

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## Por qué es importante

El diseño dirigido por eventos es lo que le permite agregar capacidades (análisis, verificación de fraude, notificaciones) simplemente suscribiéndose, sin cambios en los productores existentes.

Esta extensibilidad y resiliencia tienen un costo en forma de consistencia eventual y depuración más difícil — el compromiso central que acepta al adoptar arquitectura dirigida por eventos.