Na construção de sistemas distribuídos, uma das decisões arquiteturais mais recorrentes e pouco discutidassubestimadas é a escolha do modelo de comunicação entre serviços. Em sua forma mais simples, essa decisão costuma ser reduzida à pergunta: “Por que eu deveria usar mensageria se posso simplesmente chamar o outro serviço via HTTP?”.
À primeira vista, a chamada síncrona parece a escolha mais comumóbvia. É direta, fácil de implementar, simples de depurar e naturalmente alinhada ao modelo request/response com o qual a maioria dos desenvolvedores está familiarizada. Entretanto, essa aparente simplicidade esconde uma série de implicações arquiteturais importantesprofundas relacionadas à acoplamentoa acoplamento temporal, propagação de falhas, escalabilidade e evolução do sistema.
O objetivo deste artigo é expor, de forma técnica e pragmática, quando o HTTP síncrono é a melhor escolha, quando ele se torna um gargalo estrutural, e por que arquiteturas orientadas a mensagens existem não como moda, mas como resposta a limitações fundamentais do modelo síncrono.
O problema estrutural da comunicação síncrona
Uma chamada HTTP entre serviços não representa apenas uma troca de dados; ela cria um contrato de disponibilidade e tempo entre o chamador e o chamado. Quando um serviço A chama um serviço B de forma síncrona, três acoplamentos são introduzidos simultaneamente:
- Acoplamento temporal: B precisa estar disponível no exato momento da chamada.
- Acoplamento de latência: o tempo de resposta de B impacta diretamente o SLA de A.
- Acoplamento de falha: falhas em B tendem a propagar para A.
Em sistemas simples, isso é aceitável. Em sistemas distribuídos de média ou grande escala, isso se torna um problema estrutural.
Considere um fluxo clássico:
API Pedido@C
→ Serviço de Pagamento (HTTP)
→ Serviço de Antifraude (HTTP)
→ Serviço de Score Externo (HTTP)
Cada chamada adiciona latência, pontos de falha e dependência de disponibilidade. Um timeout em qualquer elo da cadeia compromete todo o fluxo. Mesmo com retries e circuit breakers, o sistema passa a operar sob tensão constante, onde falhas deixam de ser exceção e passam a ser parte do comportamento normal.
Esse modelo não falha por erro de implementação, ele falha porque viola princípios básicos de resiliência em sistemas distribuídos.
A ilusão do controle e o custo oculto do HTTP
Um dos principais argumentos a favor do HTTP síncrono é a sensação de controle: o serviço chamador “sabe” se a operação deu certo ou errado imediatamente. No entanto, esse controle é parcial, em grande parte, ilusório.
Timeouts, falhas de rede, respostas parciais e quedas logo após o envio da resposta tornam impossível distinguir, com 100% de certeza, se uma operação realmente falhou ou apenas falhou em comunicar o sucesso. Como consequência, o chamador precisa assumir cenários ambíguos, introduzindo retries que podem gerar efeitos colaterais indesejados se o serviço chamado não for idempotente.
Na prática, HTTP síncrono frequentemente empurra complexidade para o código de resiliência, em vez de eliminá-la.
Mensageria como desacoplamento estrutural
Arquiteturas baseadas em mensageria partem de um princípio diferente: o serviço produtor não precisa saber quando, ou nem ao menos se, o consumidor processará a mensagem imediatamente. Ele apenas precisa garantir que a intenção de negócio foi registrada e entregue.
Ao introduzir um broker (Kafka, RabbitMQ, Azure Service Bus, etc.), deslocamos a responsabilidade de entrega, buffering e retry para a infraestrutura, quebrando o acoplamento temporal entre os serviços.
O fluxo muda fundamentalmente:
Serviço A
→ publica Evento no Broker
→ Serviço B consome quando disponível
Isso transforma falhas transitórias em algo absorvível pelo sistema, em vez de propagável. O produtor segue seu fluxo independentemente da disponibilidade momentânea do consumidor.
Trade-offs reais: mensageria não é “de graça”
Apesar de seus benefícios, mensageria não é uma bala de prata. Ela introduz custos claros:
Vantagens
- Desacoplamento temporal e estrutural
- Melhor resiliência a falhas parciais
- Escalabilidade independente entre serviços
- Capacidade natural de absorver picos de carga
Desvantagens
- Complexidade operacional (brokers, monitoramento, DLQs)
- Debug mais difícil (fluxos não lineares)
- Latência eventual (não imediata)
- Necessidade obrigatória de idempotência
A decisão de usar mensageria não deve ser ideológica, mas econômica e técnica: o custo da complexidade compensa o risco mitigado?
Quando HTTP síncrono é a escolha correta
HTTP continua sendo a melhor opção quando:
- O fluxo exige resposta imediata ao usuário
- A operação é fortemente acoplada ao contexto de requisição
- O SLA do serviço chamado é alto e bem controlado
- O impacto de uma falha é pequeno ou facilmente recuperável
Exemplos:
- Autenticação e autorização
- Consultas simples (read models)
- Orquestração leve dentro de um mesmo bounded context
- APIs públicas com semântica request/response clara
Nesses cenários, introduzir mensageria apenas adicionaria latência e complexidade desnecessárias.
Quando mensageria deixa de ser opcional
Mensageria faz sentidose torna essencial quando:
- A operação não precisa ser síncrona
- O sistema precisa tolerar falhas parciais
- O volume ou pico de requisições é imprevisível
- A perda de disponibilidade de um serviço não pode travar outros
- O domínio exige consistência eventual, não imediata
Exemplos clássicos:
- Processamento de pagamentos
- Atualização de estoque
- Integrações entre domínios distintos
- Processos de longa duração (sagas)
- Eventos de domínio que disparam múltiplos consumidores
Nesses casos, insistir em HTTP síncrono normalmente resulta em código defensivo excessivo, cascatas de retry e instabilidade no sistemasistêmica.
O erro comum: misturar os dois sem critério
Um erro frequente em arquiteturas híbridas é usar mensageria como se fosse HTTP assíncrono, esperando resposta imediata, ou usar HTTP em fluxos que claramente exigem desacoplamento.
O critério correto não é técnico, mas semântico:
- “Esse fluxo exige confirmação imediata?”
- “A falha desse serviço deve bloquear o sistema?”
- “O domínio tolera o atraso?”
Responder essas perguntas corretamente define a escolha.
Insights & Takeaways
- HTTP cria acoplamento temporal e propaga falhas por padrão.
- Mensageria desloca falhas para a infraestrutura, aumentando resiliência.
- A simplicidade inicial do HTTP frequentemente cobra um custo maior em escalafrequentemente cobra juros altos em escala.
- Mensageria exige idempotência e observabilidade desde o início.
- A escolha correta depende do domínio, não da tecnologia.
Arquiteturas maduras não escolhem entre HTTP ou mensageria. Elas sabem onde cada um faz sentido e, principalmente, onde não faz.
