Problema
“Vamos quebrar em microserviços” sem mensageria confiável, sem idempotência e sem observabilidade. O sistema vira distribuído e ainda acoplado, com falhas em cascata e dados duplicados.
Solução
Definir mensagens como contrato (schema versionado), consumidores idempotentes, política de retry com backoff e DLQ. Escolher RabbitMQ (push, exchanges) vs SQS (managed, at-least-once) com base em operação e custo — não por hype.
Arquitetura
Serviço A → publica OrderPlaced v1
Fila / topic
Serviço B → consome (ack após persistência idempotente)
DLQ → alertas + replay controlado
- Outbox no monólito ou serviço escritor para não perder evento se o broker cair no commit.
- Sagas explícitas para fluxos longos; compensações documentadas.
Código
// consumer idempotente (pseudo)
async function handle(msg: OrderPlacedV1) {
const key = `order-placed:${msg.orderId}`;
if (await processedStore.has(key)) return ack();
await billingService.openInvoice(msg);
await processedStore.put(key, msg.receivedAt);
await ack();
}Performance
Batch consume onde o broker permitir; limitar concorrência por partição/chave de negócio para preservar ordenação quando necessário; compressão de payload em filas internas.
Melhorias futuras
Schema registry; tracing com trace-id propagado na mensagem; chaos tests em staging.
Conclusão
Microsserviço bom é operação + mensagem + dados pensados juntos. Artigo assim mostra que você já antecipou produção, não só diagrama.