Hay un momento concreto en el que una arquitectura síncrona deja de escalar. No avisa con antelación: aparece como latencia creciente, como timeouts encadenados entre servicios y como procesos que se quedan bloqueados esperando una respuesta que tarda más de lo que el sistema puede permitirse. La solución habitual es introducir un bus de mensajes que desacople quien produce un evento de quien lo consume. El problema es que elegir mal esa pieza rara vez tumba el sistema de inmediato. Lo que hace es complicar su operación durante años, y eso es peor porque no se nota hasta que ya no se puede cambiar sin una migración costosa.
La señal de que el modelo síncrono se ha acabado
Mientras el volumen es bajo, llamar directamente de un servicio a otro y esperar la respuesta funciona bien y es más simple de razonar. El problema aparece cuando el volumen escala: cada llamada síncrona añade latencia acumulada, cada servicio caído bloquea a los que dependen de él, y los picos de tráfico se propagan en cascada en lugar de absorberse. Cuando estos síntomas empiezan a repetirse, conviene plantearse introducir mensajería asíncrona antes de que el problema se resuelva a base de aumentar recursos, que solo compra tiempo.
Kafka: cuando el valor está en el log
Kafka tiene sentido cuando lo importante es el registro de eventos en sí, no solo su entrega puntual. Permite que varios consumidores lean el mismo flujo de eventos de forma independiente, que se pueda reprocesar el histórico cuando aparece un nuevo consumidor o un error en la lógica, y que el propio log actúe como fuente de verdad del sistema. Es la opción natural cuando se necesita alto volumen sostenido, retención de eventos durante días o semanas, y varios equipos consumiendo el mismo flujo para propósitos distintos. Su coste es la complejidad operativa: particionado, replicación y gestión de offsets exigen un nivel de administración que no siempre está justificado para volúmenes moderados.
NATS: mensajería ligera para baja latencia
NATS encaja cuando la prioridad es la latencia mínima y la simplicidad operativa, más que la retención de eventos a largo plazo. Es una opción habitual en comunicación entre microservicios y en escenarios de baja latencia donde no hace falta guardar el histórico completo del flujo. JetStream, su capa de persistencia, añade parte de las garantías de Kafka sin llegar a su misma complejidad de despliegue, lo que lo convierte en un término medio razonable cuando Kafka resulta sobredimensionado para el caso de uso.
RabbitMQ: colas con enrutamiento flexible
RabbitMQ está pensado para el patrón de colas de trabajo con enrutamiento flexible: distribuir tareas entre varios consumidores, aplicar prioridades, y encaminar mensajes según reglas de exchange y binding. Es una opción sólida cuando el problema es repartir trabajo (por ejemplo, tareas de procesamiento o notificaciones) más que mantener un registro histórico de eventos. Su modelo de entrega y confirmación (acknowledgements) está muy probado en producción, aunque escalar a volúmenes muy altos exige más cuidado que con Kafka.
Idempotencia: el problema que no se ve hasta que se duplica un mensaje
En cualquier sistema de mensajería asíncrona, un mensaje puede llegar más de una vez. Puede deberse a un reintento tras un timeout, a un consumidor que se cae después de procesar pero antes de confirmar, o a un simple reenvío. Si el consumidor no está diseñado para ser idempotente (es decir, para producir el mismo resultado sin importar cuántas veces se procese el mismo mensaje), esos duplicados generan efectos reales: un cargo repetido, un correo enviado dos veces, un stock descontado de más. La idempotencia no es un detalle de implementación, es una propiedad que hay que diseñar desde el principio, normalmente mediante claves de deduplicación o mediante operaciones que sean naturalmente idempotentes.
Reintentos: dead letter queues y backoff
Los reintentos automáticos son necesarios, pero sin control se convierten en el propio problema. Un mensaje que falla y se reintenta indefinidamente puede saturar un consumidor ya débil o generar un bucle de errores que consume recursos sin aportar valor. La combinación habitual es un backoff exponencial (espaciar los reintentos de forma creciente) junto con una cola de mensajes muertos (dead letter queue) donde acaban los mensajes que han agotado sus reintentos, para que alguien los revise en lugar de perderlos silenciosamente.
Errores típicos de primera implementación
- Tratar el bus de mensajes como una cola de tareas sin diseñar la idempotencia del consumidor.
- No definir una estrategia de reintentos y dead letter queue desde el primer día.
- Elegir Kafka por defecto sin necesitar retención de eventos ni múltiples consumidores del mismo flujo.
- Ignorar el orden de los mensajes cuando el negocio sí depende de ese orden.
- No monitorizar el lag de los consumidores, lo que oculta un consumidor que se está quedando atrás hasta que el retraso ya es un problema.
Cómo elegir
La pregunta que de verdad ayuda a decidir no es cuál es la tecnología más popular, sino qué necesita el sistema: si el valor está en el histórico de eventos y en varios consumidores independientes, Kafka. Si la prioridad es la latencia y la simplicidad operativa, NATS. Si el patrón es repartir tareas con enrutamiento flexible, RabbitMQ. Elegir a partir de esa pregunta, y diseñar la idempotencia y los reintentos desde el principio, es lo que separa una arquitectura de mensajería que aguanta el crecimiento de una que solo funciona mientras el volumen es pequeño. El equipo de desarrollo de software a medida de Irontec trabaja este tipo de decisiones de arquitectura desde la fase de diseño, junto con el despliegue de la infraestructura que las sostiene.
Y esa infraestructura, por bien diseñada que esté la mensajería, sigue dependiendo de algo tan básico como tener probada su propia recuperación ante un fallo: un broker sin un plan de backup verificado es un punto único de fallo, aunque el resto de la arquitectura sea impecable.
