Filas como contrato, não como atalho.
Por que RabbitMQ resolve problemas de acoplamento antes de resolver problemas de performance — e o que isso muda no desenho do contrato entre serviços.
1.0 O problema
Quando duas equipes integram sistemas por fila, a primeira pergunta costuma ser "qual broker é mais rápido?" — a pergunta certa é "o que essa fila promete, e para quem?"[1] Um contrato mal definido custa caro tempos depois, quando o consumidor original muda de forma silenciosa.
Neste registro, documento a decisão de tratar cada fila como uma interface versionada — não como um cabo solto entre dois serviços.
2.0 Anatomia da fila
Todo evento publicado carrega três coisas: um schema, uma versão e uma garantia de entrega. Tratar essas três explicitamente evita a maior parte dos incidentes de integração que vejo em produção.
3.0 Decisão de acoplamento
A escolha de RabbitMQ, neste caso, teve menos a ver com throughput e mais com a semântica de roteamento por exchange — ela deixa o contrato visível na topologia, não escondido em código de aplicação.
4.0 Notas de campo
- 01Versionar o schema desde o primeiro consumidor — mesmo com um único serviço.
- 02Dead-letter queues não são opcionais: são onde a falha vira dado.
- 03Métricas de fila (profundidade, idade da mensagem) importam tanto quanto latência de API.