¿Por qué un broker de mensajería?

En este artículo encontraremos respuesta a las preguntas: ¿por qué?, ¿cuándo? y ¿cómo?

Cuando trabajamos con programación asíncrona podemos encontrarnos con ciertos “bloqueos” al realizar peticiones HTTP, algo que justamente buscamos evitar al optar por esta alternativa frente a la programación síncrona (puedes recordar la diferencia entre ambas en el siguiente blog: Diferencia entre programación asíncrona y síncrona).

Cuando hacemos un llamado HTTP de la forma tradicional, sea con programación asíncrona o no, debemos esperar la respuesta del servicio externo. Incluso al usar programación asíncrona, llamar directamente al servicio produce el mismo resultado: enviar la petición, esperar, recibir la respuesta y continuar con el proceso, ya sea a nivel de código o de lógica de negocio. Esto puede generar, según el escenario, varios problemas sin una solución evidente.

Problemas principales del enfoque tradicional

Acoplamiento: en el escenario más simple, donde un servicio A consume un servicio B, existe una dependencia entre el estado o los cambios del servicio B y el servicio A. Si el servicio B llegase a fallar o a cambiar su ruta, el servicio A tendría que modificarse de alguna forma, por ejemplo recibiría un error 404 al usar una ruta obsoleta. Esto genera un claro acoplamiento, ya que obliga a que A se vea afectado por cambios que ocurren en B. En una arquitectura ideal se busca minimizar estas dependencias para evitar que cada ajuste en un servicio provoque modificaciones en otro, lo que encarece el mantenimiento y reduce la flexibilidad del sistema.

Punto único de fallo: si en el momento en que el servicio A llama al servicio B este está caído, probablemente se obtenga un retorno no exitoso por timeout. En este caso, el servicio A no tendría forma de identificar cuándo vuelve a estar disponible el servicio B y se perderá la petición, lo que puede generar problemas más graves, como pérdida de información crítica, interrupción en procesos de negocio dependientes o incluso fallos en cadena en otros servicios que esperaban esa respuesta.

Consumo de recursos: aunque usemos programación asíncrona, el servicio A sigue manteniendo conexiones abiertas mientras espera una respuesta de B. Si B tarda, por ejemplo, 10 segundos en responder, hay recursos ocupados durante ese tiempo, lo cual puede ser crítico en sistemas con miles de peticiones simultáneas.

La solución: delegar la entrega de mensajes a un intermediario

¿Qué pasa cuando agregamos un tercero a la ecuación? Surge un mensajero encargado de recibir y remitir los mensajes cuando y donde sea necesario, y que puede esperar a que los destinatarios estén disponibles para entregarlos uno a uno. Es en este punto donde entran los brokers de mensajería, cuyo nombre proviene de la idea de un intermediario o “broker” que recibe, gestiona y entrega mensajes entre aplicaciones.

Menos acoplamiento: el broker permite desacoplar a los servicios. Si B cambia su dirección, basta con configurar el broker en lugar de modificar el código de A. Esto es preferible porque ajustar el broker es una tarea de configuración centralizada, más sencilla y de menor riesgo que alterar el código de un servicio de negocio, lo que implicaría despliegues, pruebas y potenciales errores adicionales.

Persistencia de mensajes: si B no está disponible, el broker almacena los mensajes en una cola y los entrega en orden cuando B vuelva a estar en línea. Esta funcionalidad suele estar disponible por defecto en la mayoría de los brokers, aunque sus límites dependen de la configuración (por ejemplo, tamaño máximo de la cola, tiempo de retención de mensajes o políticas de expiración).

Optimización de recursos: los servicios no necesitan sostener sockets o threads (que consumen recursos) activos esperando una respuesta directa del servicio B. Con un broker, en cambio, este gestiona las entregas y los consumidores procesan los mensajes únicamente cuando están listos.

Los beneficios de implementar un broker no se limitan solo a estos, por otro lado, los brokers ayudan en diferentes escenarios, estos son algunos de los beneficios extras:

Ahora, los brokers no siempre son la solución, existen varios escenarios donde lo recomendable es usar una llamada HTTP directa.

¿Cuándo no usar un broker de mensajería?

1. cuando la operación es simple y directa, si la interacción entre servicios es muy básica, como consultar el perfil de un usuario, un broker añade complejidad innecesaria.
2. Necesidad de respuesta inmediata, en escenarios como el inicio de sesión o la validación de una tarjeta, se requiere una confirmación instantánea. Los brokers introducen asincronía, lo que significa que el flujo puede tardar.
3. Costes: cuando las peticiones entre servicios son pocas, no justifica la inversión que conlleva mantener e implementar un broker.
4. Requerimiento de consistencia inmediata, los brokers funcionan bajo el principio de eventual consistency, es decir, que los datos se sincronizan con un ligero desfase. Para casos críticos donde la consistencia debe ser instantánea, lo ideal es mantener un modelo transaccional con comunicación directa.

¿Cómo usar broker de mensajería?

Existen diversas maneras de implementar un broker de mensajería, según las necesidades de comunicación entre servicios. Una de las más comunes es el modelo publish/subscribe, donde un productor envía mensajes a un canal o tópico y múltiples consumidores los reciben de forma independiente. Otro patrón ampliamente usado es el modelo de colas de trabajo (work queue), en el que cada mensaje es consumido por un único receptor, lo que resulta útil para distribuir carga de procesamiento entre varios trabajadores. Finalmente, soluciones más completas como Kafka ofrecen no solo la entrega de mensajes, sino también almacenamiento duradero de eventos, reprocesamiento histórico y control de orden en el consumo.de recursos en sistemas distribuidos. Sin embargo, no son una solución universal: se deben evaluar los costos y el contexto antes de implementarlos.

Caso practico

A continuación se presentará un esquema sencillo de un pequeño proyecto. Este servirá para ilustrar cómo un servicio que recibe peticiones REST puede comunicarse con un backend mediante un broker de mensajería y colas. El objetivo es mostrar de forma práctica la interacción entre productor, broker y consumidor, y explicar paso a paso cómo se conectan las piezas en un escenario realista.

1. El cliente inicia la solicitud: El proceso comienza cuando el Client (un cliente o una aplicación) envía una solicitud de datos al sistema. Esta solicitud es recibida por el EntryPoint, que actúa como la puerta de entrada principal para las peticiones externas.

2. El servicio de consulta prepara la petición: El EntryPoint transfiere la solicitud al Driven-Adapter, que es un componente diseñado para interactuar con un broker de mensajería (en este caso, IBM-MQ). El Driven-Adapter utiliza un patrón de solicitud-respuesta para comunicarse con el backend. Lo que hace es colocar un mensaje en la cola 1 dentro de IBM-MQ. Esta cola está específicamente dedicada a las solicitudes del “Servicio — consultar datos de cliente”.

3. El backend procesa la solicitud: El servicio del Backend — datos de cliente está “escuchando” o consumiendo los mensajes de la cola 1. Al recibir el mensaje, el backend lo procesa y se comunica con un sistema de registro de datos, llamado iseries, para obtener la información del cliente solicitada.

4. El backend envía la respuesta: Una vez que el Backend ha recuperado los datos, coloca la respuesta en la cola 2. El Driven-Adapter, que también está “escuchando” esta cola, recupera el mensaje de respuesta. Finalmente, el EntryPoint recibe la respuesta y la envía de vuelta al Client original.