Capitulo 2: Event-driven vs REST APIs: cuándo y por qué elegir cada uno

Al diseñar la arquitectura de un sistema distribuido, una de las decisiones clave es cómo se comunican los distintos servicios. En la práctica, dos estilos son los más habituales: las APIs REST (interacción sincrónica) y las arquitecturas dirigidas por eventos (event-driven, interacción asíncrona).

No se trata de elegir un “ganador”, sino de entender qué problema resuelve cada enfoque, qué concesiones implica y en qué contexto aporta más valor.

1. Qué es una API REST

Una API REST expone recursos de negocio a través de HTTP, utilizando verbos estándar (GET, POST, PUT, DELETE, entre otros). El modelo de interacción es directo:

1. Un cliente envía una petición a un endpoint.

2. El servidor procesa la solicitud.

3. El servidor responde de forma inmediata con un resultado (éxito o error).

Características principales:

• Comunicación sincrónica
  El cliente espera la respuesta para continuar. Esta relación directa simplifica el modelo de interacción.

• Contrato explícito
  Cada endpoint define un contrato claro (URL, método HTTP, esquema de datos), habitualmente documentado con OpenAPI/Swagger.

• Orientación a recursos
  Encaja de forma natural con operaciones CRUD sobre entidades de negocio: usuarios, pedidos, productos, entre otros.

• Depuración relativamente simple
  Una petición se puede rastrear de extremo a extremo mediante registros de entrada y salida, trazas HTTP y herramientas de observabilidad.

REST es el enfoque más utilizado para exponer servicios a aplicaciones web, aplicaciones móviles e integraciones con terceros.

2. Qué es una arquitectura event-driven

En una arquitectura event-driven, los servicios se comunican mediante eventos de negocio:

Algo relevante ocurrió: PedidoCreado, PagoConfirmado, StockReservado, etc.

En lugar de invocar directamente a otro servicio, un servicio emisor (también llamado publicador) genera un evento y lo publica en una plataforma de mensajería (por ejemplo, Kafka, RabbitMQ o Pulsar). Uno o varios servicios consumidores se suscriben a esa clase de eventos y ejecutan la lógica correspondiente cuando los reciben.

Características principales:

• Comunicación asíncrona
  El servicio emisor no espera una respuesta inmediata. Publica el evento y continúa con su ejecución.

• Bajo acoplamiento entre servicios
  El servicio emisor no necesita conocer qué servicios consumen el evento ni cuántos son. Solo depende del esquema del evento.

• Escalabilidad horizontal
  Los servicios consumidores se pueden escalar en paralelo para procesar grandes volúmenes de eventos.

• Modelo alineado con el negocio
  La secuencia de eventos refleja el flujo real de negocio, lo que facilita la auditabilidad y el análisis de procesos.

En muchos casos, los eventos se almacenan y se utilizan para reconstruir estados (event sourcing), alimentar analítica en tiempo real o cubrir requisitos de auditoría.

3. Diferencias fundamentales entre REST y event-driven

3.1 Modelo de interacción

• REST
  Patrón petición–respuesta (request–response). El cliente invoca un servicio concreto y recibe una respuesta directa.

• Event-driven
  Patrón publicación–suscripción (publish–subscribe). Un servicio emisor publica eventos sin conocer a los destinatarios; los servicios consumidores reaccionan cuando los reciben.

3.2 Tipo de acoplamiento

• REST

  • Acoplamiento temporal: cliente y servidor deben estar disponibles al mismo tiempo.

  • Acoplamiento estructural: el cliente depende del contrato exacto del endpoint.

• Event-driven

  • Menor acoplamiento temporal: los servicios pueden estar temporalmente fuera de servicio y procesar los eventos pendientes posteriormente.

  • El acoplamiento se realiza a través del esquema del evento, que puede evolucionar de forma controlada mediante versionado.

3.3 Consistencia de datos

• REST
  Facilita escenarios de consistencia fuerte dentro de los límites de una operación, por ejemplo, una transacción sobre una misma base de datos.

• Event-driven
  Favorece modelos de consistencia eventual en sistemas distribuidos. Los cambios se propagan mediante eventos y los distintos servicios alcanzan el mismo estado con cierto retraso.

3.4 Observabilidad y depuración

• REST
  La trayectoria de una petición suele ser lineal y sencilla de seguir con trazas HTTP.

• Event-driven
  Un flujo de negocio puede involucrar múltiples eventos, colas y servicios. Para mantener visibilidad se requieren prácticas específicas:

  • Identificadores de correlación (Correlation IDs).

  • Registros estructurados.

  • Trazas distribuidas adaptadas a mensajería asíncrona.

3.5 Complejidad operativa

• REST
  Infraestructura conocida: balanceadores, API gateways, certificados TLS, monitoreo HTTP.

• Event-driven
  Introduce componentes adicionales:

  • Plataforma de eventos.

  • Gestión de particiones, offsets y reintentos.

  • Dead Letter Queues (DLQ) para mensajes que no se pueden procesar.

  • Herramientas específicas de monitoreo y operación.

La complejidad técnica y operativa es mayor, pero a cambio se obtienen ventajas significativas en desac acoplamiento y escalabilidad.

4. Cuándo elegir REST

REST suele ser la opción adecuada cuando se cumplen una o varias de las siguientes condiciones.

4.1 Se requiere respuesta inmediata al usuario

Escenarios interactivos en los que el usuario necesita ver el resultado al instante:

• Inicio de sesión y registro de usuarios.

• Actualización de datos de perfil.

• Consultas en tiempo real (por ejemplo, estado actual de una cuenta).

4.2 Operaciones CRUD simples

Casos en los que se gestionan recursos de forma directa:

• Alta, baja y modificación de entidades de negocio.

• Configuraciones administrativas.

• Servicios internos con lógica acotada.

La semántica de HTTP (GET, POST, PUT, DELETE) encaja de forma natural en este tipo de operaciones.

4.3 Integraciones con terceros

La mayoría de proveedores externos exponen APIs REST:

• Pasarelas de pago.

• Proveedores de identidad.

• Plataformas SaaS en general.

Esto simplifica la integración y permite aprovechar SDKs, bibliotecas y herramientas ya disponibles.

4.4 Sistemas pequeños o con pocos servicios

En sistemas con complejidad limitada, introducir mensajería asíncrona y una plataforma de eventos puede no justificar el aumento de complejidad de diseño, implementación y operación.

4.5 Necesidad de control transaccional acotado

Operaciones en las que se requiere atomicidad dentro de límites claros:

• Actualizar un recurso y obtener su nuevo estado como parte de la misma llamada.

• Operaciones de escritura con validaciones estrictas y resultado inmediato.

5. Cuándo elegir una arquitectura event-driven

La arquitectura dirigida por eventos aporta ventajas claras en los siguientes contextos.

5.1 Desacoplar equipos y servicios

Cuando múltiples servicios deben reaccionar a un mismo hecho de negocio:

• Ante un evento PedidoCreado se pueden desencadenar:

  • Facturación.

  • Reserva de stock.

  • Envío de notificaciones.

  • Integraciones con logística o CRM.

Nuevos servicios consumidores pueden suscribirse al evento sin modificar el servicio emisor ni el contrato de sus APIs REST.

5.2 Procesos de negocio largos y distribuidos

Flujos que atraviesan varios servicios y tienen duración extendida (minutos, horas o días):

• Incorporación de nuevos clientes (onboarding).

• Procesos de aprobación con múltiples etapas.

• Workflows que requieren varios pasos y validaciones en distintos dominios.

La secuencia de eventos modela de forma explícita las etapas del proceso.

5.3 Escalabilidad y alto volumen de procesamiento

Casos de uso con un volumen elevado de mensajes o eventos:

• Telemetría y registros de aplicaciones.

• Seguimiento de actividad de usuarios.

• Procesamiento de datos en flujo continuo (streaming).

La posibilidad de escalar de manera independiente los servicios consumidores permite absorber picos de carga sin necesidad de sobredimensionar toda la plataforma.

5.4 Resiliencia ante fallos

La mensajería asíncrona permite:

• Reintentos automáticos ante fallos temporales.

• Persistencia de eventos para reprocesamiento.

• Aislar los fallos de un servicio y evitar que se propaguen al resto del sistema.

En lugar de perder solicitudes cuando un servicio está fuera de servicio, estas se mantienen en cola hasta que el servicio vuelve a estar disponible.

5.5 Analítica, auditoría y event sourcing

Cuando el registro detallado de lo que ocurre en el negocio es crítico:

• Auditoría de cambios en datos sensibles.

• Reconstrucción de estados a partir de eventos históricos.

• Construcción de vistas materializadas para informes y análisis.

La arquitectura basada en eventos se ajusta de forma natural a estos requerimientos.

6. Patrones híbridos: REST hacia el exterior, eventos en el interior

En sistemas maduros es habitual combinar ambos enfoques:

• REST en la capa de borde
  Para exponer servicios a aplicaciones web, aplicaciones móviles y terceros.

• Event-driven en el interior del sistema
  Para la comunicación entre microservicios y la coordinación de procesos de negocio.

Ejemplo de flujo híbrido:

1. El cliente realiza una llamada REST para crear un pedido.

2. El servicio de pedidos persiste la información y:

   • Devuelve de inmediato una respuesta al cliente (por ejemplo, “pedido recibido”).

   • Publica un evento PedidoCreado en la plataforma de eventos.

3. Los servicios de facturación, stock, notificaciones y logística se suscriben al evento PedidoCreado y ejecutan sus acciones de forma independiente.

Patrones que suelen acompañar este enfoque:

• Outbox pattern
  Garantiza que la escritura en la base de datos de la aplicación y la publicación del evento se realizan de forma consistente, evitando desincronización entre estado y eventos.

• Change Data Capture (CDC)
  Permite generar eventos a partir de cambios en la base de datos, sin modificar la lógica principal de la aplicación.

• Webhooks y WebSockets combinados con eventos internos
  Hacia el exterior se utilizan mecanismos basados en HTTP, mientras que internamente el sistema se articula mediante eventos.

7. Errores comunes al adoptar REST o event-driven

7.1 Resolver todos los casos únicamente con REST

Forzar flujos complejos, que involucran varios servicios, mediante cadenas de llamadas REST:

• Aumenta el acoplamiento entre servicios.

• Genera cascadas de fallos y tiempos de espera elevados.

• Dificulta la evolución y el mantenimiento de la arquitectura.

7.2 Adoptar event-driven sin un objetivo claro

Introducir una plataforma de eventos en sistemas pequeños o de baja complejidad solo por tendencia tecnológica:

• Incrementa la complejidad innecesariamente.

• Complica la operación y la depuración de problemas que podrían resolverse con un diseño más simple.

7.3 Confundir eventos con comandos

• Un evento describe algo que ya ocurrió: PagoAprobado.

• Un comando representa una intención u orden: ProcesarPago.

Mezclar ambos conceptos genera ambigüedad en el diseño y en las responsabilidades de los servicios.

7.4 Diseñar eventos sin un modelo de dominio claro

Definir eventos con nombres genéricos o excesivamente técnicos, que no reflejan el lenguaje del negocio:

• Complica la comprensión del sistema.

• Dificulta la evolución del modelo y la incorporación de nuevos servicios.

7.5 Descuidar la observabilidad

Implementar mensajería asíncrona sin:

• Identificadores de correlación coherentes.

• Métricas claras de colas, retrasos y reintentos.

• Trazas distribuidas adaptadas a un entorno event-driven.

El sistema puede funcionar, pero resulta difícil de operar y de diagnosticar en producción.

8. Criterios prácticos para tomar la decisión

Una forma pragmática de decidir entre REST y event-driven es responder a las siguientes preguntas:

1. ¿El usuario necesita la respuesta en el mismo momento?

   • Sí → priorizar REST.

   • No necesariamente → considerar un enfoque event-driven.

2. ¿Intervienen varios servicios que deben reaccionar a un mismo hecho de negocio?

   • Sí → un evento compartido es un buen candidato.

   • No → REST puede ser suficiente.

3. ¿El flujo es corto y acotado, o largo y distribuido?

   • Flujo corto o simple → REST.

   • Flujo largo o con múltiples servicios → event-driven.

4. ¿El equipo está preparado para operar una plataforma de eventos?

   • Si la respuesta es no, la adopción de event-driven requiere una decisión consciente, formación y herramientas adecuadas.

5. ¿La auditabilidad y el análisis de eventos de negocio son requisitos prioritarios?

   • Si la respuesta es sí, una arquitectura event-driven aporta ventajas relevantes.

9. Conclusión

REST y las arquitecturas dirigidas por eventos no son enfoques excluyentes. Cada uno resuelve problemas distintos:

• REST ofrece simplicidad, claridad y control para interacciones directas, sincrónicas y acotadas.

• Event-driven proporciona desacoplamiento, escalabilidad y un modelo más adecuado para procesos complejos y distribuidos.

Las arquitecturas más robustas suelen combinar ambos estilos: REST en los límites del sistema y un backbone de eventos (es decir, una columna vertebral de mensajería basada en eventos que articula la comunicación interna entre servicios) en el interior. La decisión debe basarse en las necesidades reales del dominio, en los requisitos no funcionales y en la madurez del equipo responsable de diseñar, operar y evolucionar la solución.

Hasta aquí por hoy. Gracias por acompañarme.