Infosistemas
Infosistemas: a failure contract for RabbitMQ messaging
Intermittent failures between microservices with no contract for retry, DLQ, or duplication. Adding more consumers only pushed the overload elsewhere.
~98% fewer intermittent failures in critical flows
Publicação confirmada, consumo com prefetch controlado, retry com backoff e DLQ por fluxo. Escalar só consumidores fica de fora do desenho.
Context
Infosistemas operates management platforms for rental companies, fleets, and automakers. The work happened in the architecture team, in collaboration with DevOps, SREs, and DBAs, between February 2025 and May 2026.
This case covers the messaging track. Other tracks from the same experience (ERP security, signing journeys, fiscal integrations) exist in the sources but are not included here as extra numbers or claims.
Constraints
Critical flows crossed microservices. Failure was intermittent: the same operation could complete on one run and fail on the next. Raising concurrency or prefetch without criteria transferred overload to consumers, services, or downstream databases.
Problem
Messages stopped completing the expected flow. Investigating partial failure was hard. There was no explicit contract for temporary failure, permanent failure, duplication, or poison messages.
Decision
Messaging was redesigned to make failure behavior predictable:
- durable queues;
- per-flow DLQ, so a message that must neither disappear nor repeat without control has a place to go;
- retry with backoff for temporary unavailability;
- idempotency and deduplication in the consumer, because duplicated delivery must not repeat a business effect;
- publisher confirms, to reduce uncertainty at publish time;
- prefetch tuning, instead of opening concurrency indiscriminately.
Discarded alternative
Treating the problem as a capacity shortage (more consumers, more prefetch) without changing the failure contract. That would move the bottleneck and keep silent loss or duplication.
Implementation
The redesign applied these mechanisms to the critical flows: confirmed publishing, durable queues with controlled prefetch, idempotent consumers, retry with backoff, and per-flow DLQ. Operations gained a predictable path for temporary failure and for permanent failure, instead of relying on ad hoc reprocessing.
Result
The recorded reduction in intermittent failures in critical flows between microservices was approximately 98%. The number describes those flows after the redesign, not the entire company operation nor other tracks.
Limitations
Metrics from other tracks that are still pending method or confirmation are left out. If volume or the microservice map changes so that DLQ and prefetch no longer isolate failure, tuning must be revisited with queue and consumer telemetry.