Infosistemas
Infosistemas: contrato de fallo en la mensajería RabbitMQ
Fallos intermitentes entre microservicios sin contrato para retry, DLQ o duplicidad. Más consumidores solo desplazaban la sobrecarga.
~98% reducción de fallos intermitentes en los flujos críticos
Publicação confirmada, consumo com prefetch controlado, retry com backoff e DLQ por fluxo. Escalar só consumidores fica de fora do desenho.
Contexto
Infosistemas opera plataformas de gestión para arrendadoras, flotas y automotrices. El trabajo ocurrió en el equipo de arquitectura, en colaboración con DevOps, SREs y DBAs, entre febrero de 2025 y mayo de 2026.
Este caso cubre el frente de mensajería. Otros frentes de la misma experiencia (seguridad del ERP, jornadas de firma, integraciones fiscales) existen en las fuentes, pero no entran aquí como número o afirmación extra.
Restricciones
Los flujos críticos cruzaban microservicios. El fallo era intermitente: la misma operación podía completarse en una ejecución y no completarse en la siguiente. Aumentar concurrencia o prefetch sin criterio transfería sobrecarga a consumidores, servicios o bases downstream.
Problema
Los mensajes dejaban de completar el flujo esperado. Investigar un fallo parcial era difícil. No había contrato explícito para fallo temporal, fallo permanente, duplicidad o poison message.
Decisión
La mensajería fue rediseñada para volver predecible el comportamiento ante fallos:
- colas durables;
- DLQ por flujo, para el mensaje que no debe desaparecer ni repetirse sin control;
- retry con backoff para indisponibilidad temporal;
- idempotencia y deduplicación en el consumidor, porque la entrega duplicada no puede repetir el efecto de negocio;
- publisher confirms, para reducir la incertidumbre en la publicación;
- ajuste de prefetch, en lugar de abrir concurrencia indiscriminada.
Alternativa descartada
Tratar el problema como falta de capacidad (más consumidores, más prefetch) sin cambiar el contrato de fallo. Eso movería el cuello de botella y mantendría pérdida o duplicidad silenciosa.
Implementación
El rediseño colocó estos mecanismos en los flujos críticos: publicación confirmada, cola durable con prefetch controlado, consumidor idempotente, retry con backoff y DLQ por flujo. La operación pasó a tener un camino predecible para el fallo temporal y para el fallo permanente, en lugar de depender de reprocesamiento ad hoc.
Resultado
La reducción registrada en los fallos intermitentes de los flujos críticos entre microservicios fue de aproximadamente el 98%. El número describe esos flujos tras el rediseño, no la operación entera de la empresa ni otros frentes.
Limitaciones
Las métricas de otros frentes aún pendientes de método o confirmación quedan fuera. Si la volumetría o el mapa de microservicios cambia de forma que DLQ y prefetch dejen de aislar el fallo, el tuning debe revisarse con telemetría de colas y de consumidores.