RabbitMQ: o que ele faz de verdade (e por que muita gente usa errado)
RabbitMQ é uma daquelas coisas que muita gente usa, mas pouca gente entende o que tá acontecendo ali no meio.
A maioria aprende assim:
“é só um lugar que você manda uma mensagem
e outro sistema consome depois”
E pronto.
O problema é que, quando você não entende o modelo mental do RabbitMQ (e o problema que ele resolve), você começa a usar errado.
Ou pior: usa quando nem precisava.
O problema real que o RabbitMQ resolve
Imagina uma loja.
O usuário faz um pedido e o sistema precisa:
- registrar o pedido
- processar pagamento (externo)
- emitir nota fiscal (externo)
- atualizar estoque
- enviar e-mail (externo)
Se você fizer isso em sequência via HTTP… o usuário fica preso esperando tudo e seu sistema vira um monólito distribuído.
Fluxo típico ruim com HTTP em cadeia
HTTP acopla tempo: um serviço espera o outro.
Se um cair, trava geral. Se um ficar lento, todo mundo sofre.
Onde o RabbitMQ entra
Com mensageria, você responde rápido pro usuário e joga o resto pro “tempo do sistema”.
Fluxo com RabbitMQ (desacoplado)
RabbitMQ não é “substituto de HTTP”.
Ele existe pra tirar trabalho pesado do caminho do usuário.
Modelo mental do RabbitMQ (o principal)
O RabbitMQ segue isso aqui:
Producer → Exchange → Queue → Consumer
E isso é o que quase ninguém guarda:
👉 Producer nunca manda direto pra fila.
Ele manda pra uma Exchange, e a Exchange decide pra onde vai.
Visão geral do fluxo
A fila não pensa.
Quem pensa é a Exchange.
Producer, Exchange, Queue, Consumer
- Producer: quem publica (sua API, um worker, um serviço).
- Exchange: roteia a mensagem.
- Queue: só armazena (FIFO).
- Consumer: processa.
Tipos de Exchange no RabbitMQ
1) Direct Exchange (match exato)
Se a routing key bate, a mensagem vai.
2) Fanout Exchange (broadcast)
Ignora routing key.
Chegou? Espalhou pra todo mundo conectado.
3) Topic Exchange (padrões com * e #)
Aqui você começa a tratar como evento de verdade:
order.createdorder.paidorder.error
E consumidores podem usar padrões:
order.*(uma palavra depois)order.#(zero ou mais palavras depois)
Quando você começa a usar Topic bem, seu sistema tende a ficar mais organizado e escalável.
4) Headers Exchange (roteamento por cabeçalho)
Em vez de routing key, decide pelo header:
country=BRlocale=pt-BRregion=south
ACK: por que a mensagem “volta” (e isso é bom)
Aqui separa quem usa RabbitMQ direito de quem perde mensagem em produção.
- Consumiu e deu ACK → remove da fila.
- Consumiu e caiu antes do ACK → volta pra fila.
ACK vs crash
Muita gente acha que isso é bug.
Não é. É garantia.
RabbitMQ vs Kafka (não confunde)
RabbitMQ:
- tarefa
- garante processamento
- remove mensagem depois do consumo
Kafka:
- stream de eventos
- mantém histórico
- lê quando e quantas vezes quiser
Comparação visual (mental model)
RabbitMQ é tarefa.
Kafka é stream.
Usar um no lugar do outro é pedir pra sofrer.
Quando usar RabbitMQ (e quando não usar)
Use RabbitMQ quando:
- precisa desacoplar sistemas
- precisa background / processamento assíncrono
- precisa lidar com falha e retry
Não use quando:
- precisa resposta imediata
- o fluxo é simples
- HTTP resolve
Fechando
RabbitMQ não é complicado.
O que complica é usar sem entender o modelo.
Se você entendeu Producer → Exchange → Queue → Consumer,
você já entende RabbitMQ melhor do que muita gente que usa em produção.