Síncrono ou assíncrono: a decisão que define seu sistema
Chamar e esperar ou publicar e seguir: o acoplamento temporal, as duas perguntas que decidem, a heurística de separar promessa de execução e os dois erros simétricos.
Toda integração entre dois sistemas começa com uma decisão silenciosa que vai definir o comportamento de falha, a latência e o acoplamento pelos próximos anos: chamar e esperar, ou publicar e seguir? A maioria dos times decide por inércia (síncrono, porque é o natural do HTTP), e descobre as consequências no primeiro pico ou na primeira indisponibilidade em cadeia.
Este artigo fecha a série de mensageria com o critério para essa escolha.
A diferença de verdade: acoplamento temporal
Síncrono (request/response): quem chama espera a resposta para continuar. Simples, imediato, e cria um contrato duro: os dois sistemas precisam estar saudáveis ao mesmo tempo. A indisponibilidade de um vira indisponibilidade do outro.
Assíncrono (mensagens/eventos): quem envia segue a vida; quem consome processa no seu ritmo. Os sistemas ficam desacoplados no tempo: o consumidor pode estar lento, reiniciando ou em deploy, e o produtor nem percebe: a fila absorve.
A consequência composta aparece nas cadeias: quatro serviços síncronos em série multiplicam latências e disponibilidades (99,9%⁴ ≈ 99,6%: quase 4x mais downtime). Cadeias assíncronas isolam falhas: o elo lento atrasa o processamento, não derruba a corrente.
O critério em duas perguntas
1. Quem chama precisa da resposta para continuar AGORA?
- "Este cupom é válido?", "qual o preço atual?", "o login está correto?" → o usuário está parado esperando: síncrono. Fingir assincronismo aqui só adiciona complexidade e um problema de UX.
- "Envie o e-mail de boas-vindas", "atualize o índice de busca", "notifique o financeiro" → ninguém precisa do resultado nesta requisição: assíncrono, sem hesitar.
2. Quantos interessados existem no fato?
- Um respondedor para uma pergunta: chamada direta.
- Muitos interessados no mesmo evento: publicação, ou você acaba de criar o serviço-maestro que conhece todo mundo.
E a heurística de ouro para o caso ambíguo: separe a promessa da execução. O checkout responde síncrono "pedido recebido" em 200ms (grava e enfileira) e o mundo todo (estoque, fiscal, e-mail) acontece assíncrono atrás. O usuário tem resposta imediata; o sistema tem resiliência. É o desenho de praticamente todo e-commerce que escala.
O que cada caminho cobra
O síncrono cobra resiliência explícita: timeout em toda chamada (sem timeout, a lentidão alheia vira a sua), retry com backoff e idempotência do outro lado, circuit breaker para parar de insistir no que está caído, e fallback quando possível.
O assíncrono cobra maturidade operacional: broker bem escolhido, DLQ com alarme, consumidores idempotentes, consistência eventual que o negócio aceite ("o e-mail chega em segundos, não no mesmo instante"), e rastreabilidade com IDs de correlação, porque o fluxo deixou de ser uma pilha de chamadas.
Não existe caminho grátis; existe caminho adequado ao requisito.
Os dois erros simétricos
- Tudo síncrono (o padrão por inércia): o sistema vira um castelo de cartas onde o serviço de e-mail lento derruba o checkout. Se um serviço "auxiliar" consegue tirar seu fluxo principal do ar, a integração está no modo errado.
- Tudo assíncrono (o padrão por ideologia): consultas simples viram sagas com callback, o time inteiro debugando "onde parou minha mensagem" para responder o preço de um produto. Assincronismo onde se precisava de resposta é complexidade sem retorno.
Sistemas maduros são híbridos deliberados: síncrono nas perguntas do caminho crítico do usuário, assíncrono nos fatos e nas consequências. E a decisão de cada integração fica registrada num ADR, com o porquê.
O mapa das suas integrações
Um exercício que fazemos em consultoria e você pode fazer hoje: liste as 10 integrações do seu sistema e marque: é pergunta ou é fato? Precisa da resposta agora? Quantos interessados? O desalinhamento entre a natureza da integração e o modo escolhido é onde moram seus incidentes em cadeia, e redesenhar essas fronteiras é parte do nosso serviço de Arquitetura de Software.
Qual serviço "auxiliar" consegue derrubar seu fluxo principal hoje? Conte para a IA da Rabelo Digital, aqui no canto da tela, e ela desenha o desacoplamento. Sem formulário, sem espera.
Deixe um Comentário