Request síncrono, job assíncrono ou evento: como decidir sem ritual

O problema

Quando o time aprende fila, worker e evento, existe um risco engraçado:

de repente tudo parece problema de arquitetura distribuída.

Mas muito fluxo ainda devia ser só uma request bem feita.

E o contrário também acontece:

request web segurando:

• geração de relatório
• envio de lote
• integração lenta
• processamento pesado

até estourar timeout ou cansar usuário.

O problema não é gostar demais de síncrono ou assíncrono.

É escolher sem critério.

Modelo mental

Três perguntas costumam decidir bem:

1. o usuário precisa do resultado agora?
2. o trabalho é pesado, lento ou incerto demais para o caminho principal?
3. outros fluxos precisam reagir a isso sem acoplamento direto?

Isso normalmente aponta para um dos três formatos:

• request síncrono
• job assíncrono
• evento

Quando request síncrono faz mais sentido

Request síncrono costuma ser melhor quando:

• o usuário precisa da resposta para seguir
• a operação é curta e previsível
• a falha precisa voltar imediatamente
• o sistema só faz sentido se confirmar aquilo na hora

Exemplos:

• autenticar login
• validar cupom e calcular total final
• criar recurso pequeno e devolver identificador

O ganho aqui é clareza.

Você evita transformar operação simples em saga desnecessária.

Quando job assíncrono entra melhor

Job assíncrono faz sentido quando:

• o trabalho demora demais
• pode falhar de forma transitória
• o usuário tolera acompanhar estado depois
• o throughput melhora tirando aquilo do request principal

Exemplos:

• exportar CSV
• processar mídia
• recalcular muita coisa
• importar arquivo grande

Mas mover para job não encerra a discussão.

Você também precisa responder:

• onde o estado do job fica?
• como o usuário acompanha progresso?
• o que acontece em retry?
• o que é falha final?

Quando evento realmente ajuda

Evento costuma entrar quando uma ação principal já aconteceu e outros fluxos podem reagir depois.

Exemplos:

• pedido pago
• usuário criado
• assinatura cancelada

A lógica é:

o fluxo principal confirma o fato, e outros consumidores reagem sem acoplamento direto.

Isso ajuda quando:

• existem múltiplos interessados
• nem todos precisam responder no mesmo request
• você quer reduzir dependência direta entre serviços ou módulos

Mas evento não é “job com nome chique”.

Ele muda contrato, observabilidade e forma de falha.

Um erro comum

Um erro comum é empilhar tudo:

• request recebe
• já publica evento
• já cria job
• já espera callback

tudo sem semântica clara.

Aí ninguém sabe mais:

• qual etapa é obrigatória
• qual é eventual
• qual é side effect
• qual é confirmação para o usuário

Arquitetura boa deixa isso explícito.

Exemplo simples

Imagine “finalizar compra”.

Parte síncrona:

• validar carrinho
• reservar estoque
• autorizar pagamento
• devolver confirmação do pedido

Parte assíncrona:

• gerar nota
• mandar email
• publicar analytics

Parte orientada a evento:

• “pedido confirmado” dispara reações em antifraude, CRM ou ERP

Se você tentar colocar tudo na request:

• a latência sobe
• a superfície de falha aumenta

Se jogar tudo em evento:

• o usuário perde confirmação clara
• o fluxo principal fica nebuloso

Como um senior pensa

Quem decide melhor não começa por tecnologia.

Começa por semântica:

• o que precisa estar pronto para o usuário confiar?
• o que pode acontecer depois?
• o que outras partes do sistema só precisam observar?

Em frase curta:

síncrono confirma, job processa, evento propaga

Não é sempre tão limpo.

Mas essa frase ajuda muito.

Ângulo de entrevista

Esse tema aparece bastante em system design, backend e product engineering.

O entrevistador normalmente quer ver se você sabe:

• justificar latência
• separar caminho crítico de side effect
• lidar com estado intermediário
• explicar por que evento ou fila ajudariam de verdade

Resposta forte costuma soar assim:

“Eu manteria síncrono só o que precisa confirmar valor para o usuário. O trabalho pesado ou tolerante a espera sairia para job, e eu usaria evento quando outros consumidores precisassem reagir sem acoplamento direto.”

Isso transmite julgamento.

Não ritual.