Era pra ser uma simples compra num app de delivery.
O usuário clicou em “finalizar pedido”, a tela ficou pensando… e pensando… e nada. Depois de 10 segundos, apareceu um erro. O usuário desistiu. Mas — surpresa — minutos depois, o pedido chegou mesmo assim. Sim, foi processado. O sistema só não soube como dizer isso direito.
Ou pior: o usuário ficou esperando, perdeu a paciência e decidiu comprar em outro lugar.
Parece um bug, mas não é. É só a escolha errada de comunicação: tudo feito de forma síncrona. E aí, bastou a API de pagamento oscilar por 3 segundos pra transformar um simples pedido em uma dor de cabeça.
(“Ah, mas 3 segundos não é nada!” — é o que muitos pensam… até ver o estrago que um retry automático mal implementado pode causar. Inclusive, falo bastante disso na aula do CaD sobre Retries e falhas transitórias. Spoiler: o problema não é a falha em si, mas como você lida com ela. 🔥)
Sync parece mais rápido, mas será que é melhor?
Na maioria dos sistemas que eu vejo por aí, comunicação síncrona ainda é o muito comum — e com razão, em muitos casos ela é mesmo necessária. Parece simples, direta: o sistema A chama o B, espera a resposta e pronto. A resposta chega “na hora”, o usuário tem um retorno imediato e tudo certo… certo?… Nem sempre.
A verdade é que nem todo “imediato” agrega valor. Na maioria das vezes, o usuário só quer uma confirmação de que o pedido foi recebido. Ele não precisa saber agora se a fatura foi emitida, se a notificação foi enviada ou se o estoque foi debitado. E esperar 10 segundos por algo que ele nem precisava saber naquele momento pode ser mais frustrante do que receber um “Pedido/Requisição feita com sucesso, ela esta sendo processada”
Além disso, comunicação síncrona exige:
- Compute disponível na hora;
- Alta disponibilidade da cadeia inteira;
- Tratamento de falhas imediato.
Traduzindo: mais custo, mais complexidade, e mais pontos únicos de falha. E vou te dizer, não é só sobre colocar 2x mais servidores ali na borda… na verdade você precisa garantir que TODA sua infra tenha capacidade de escalar de acordo com quantidade de TPS…
Com comunicação assíncrona, você consegue inclusive controlar o ritmo de processamento com base no compute disponível. E convenhamos… em muitos cenários, levar 1, 5, 10 ou até 60 minutos não muda nada pro usuário. Já reparou que alguns e-commerces processam o pagamento horas depois da compra? E tá tudo bem.
“Ah, mas se o pagamento demora 8 horas, eu posso atrasar a entrega por 8 horas também?”
Depende. Essa é uma decisão de negócio — que precisa ser tomada com base em dados. E tem casos reais por aí onde entregar o produto antes mesmo da confirmação do pagamento saiu mais barato do que manter infraestrutura capaz de processar tudo em tempo real. É isso mesmo.
Cada escolha tem seu custo, seu risco e seus benefícios. O importante é tomar decisões baseadas em datapoints, e não só no “é melhor fazer na hora”.
Então Async é a bala de prata?
Nops…A comunicação assíncrona — via eventos, mensagens, filas — resolve muito bem o cenário acima. Você não perde o evento, porque assim que ele é recebido, ele entra numa fila e será processado. Mesmo que o sistema de pagamento esteja fora do ar, você não precisa da interação do usuário de novo. O pedido está lá, salvo, e será processado quando possível.
Mais do que isso:
- Você pode reprocessar com retentativas (ex: retries automáticos via Kafka ou SQS);
- Pode escalar consumidores separadamente;
- Ganha resiliência contra falhas pontuais;
- E ainda desacopla os serviços.
Mas nem tudo são flores. Implementar comunicação assíncrona exige:
- Garantia de idempotência (senão você duplica tudo!);
- Visibilidade e rastreabilidade (debug de evento é outra história);
- Tratamento de dead-letter queues e mensagens inválidas;
- Controle de ordenação (às vezes a ordem importa e o async bagunça isso).
- Mudança em componentes de arquitetura.
E dá pra usar os dois? Claro que sim.
Na prática, os sistemas modernos usam um mix de sync e async.
Exemplos de quando usar síncrono:
- Login/autenticação
- Consulta de saldo ou limite de crédito
- Geração de boleto ou código Pix
- Visualização de pedidos ou dados pessoais
- Validação de cupom de desconto
- Cálculo de frete em tempo real
- Autorização de cartão em tempo real (pré-aprovação)
- Confirmação de agendamento ou reserva de horário
- Check-in em eventos ou locais com QR Code
- Atualização crítica que precisa refletir instantaneamente na interface
Exemplos de quando usar assíncrono:
- Criação de pedidos
- Upload de arquivos
- Emissão de nota fiscal
- Disparo de notificações internas e externas
- Integrações com ERPs e sistemas legados
- Processamento de antifraude
- Enriquecimento de dados
- Geração de relatórios
- Envio de e-mails, SMS, push
- Processamento de faturas ou logs
- Atualização de dados cadastrais
- Sincronização com sistemas terceiros
- Solicitação de cancelamento
- …
Na dúvida, pergunte: “O usuário precisa dessa resposta agora ou só quer saber que a ação foi recebida?”
Conclusão
Como sempre falo no CAD, não existe padrão de arquitetura que não tenha nenhum tradeoff, sim toda escolha tem seu tradeoff.
Síncrono é simples, direto… e frágil. Assíncrono é robusto, escalável… e complexo.
O papel da arquitetura não é escolher o “melhor”, mas o mais adequado pro seu cenário. E quanto mais você conhece os prós e contras de cada abordagem, melhor você consegue compor soluções que são modernas, resilientes e de alta qualidade.
Se curtiu esse conteúdo e quer se aprofundar em decisões arquiteturais que realmente fazem diferença no dia a dia, vem fazer parte da Comunidade de Arquitetura Descomplicada (CaD).
🚀 Saiba mais em: https://mugnos-it.com/cad/
Abraços,
Douglas Mugnos
MUGNOS-IT 🚀
