Filas e webhooks
Uma atualização que chega uma vez
Um pagamento, um pedido ou uma mudança de status entra uma vez. Se o sistema cai, a atualização não se perde. Uma chamada que não veio de quem enviou é recusada.
Exemplos
O problema de engenharia, em alguns formatos. Uma confirmação, uma assinatura, e uma queda que não pode perder a mensagem.
- Fluxos de alto volume. Consumidores Kafka confirmam o offset só depois que a escrita deu certo, para uma queda não perder a mensagem.
- Webhooks de terceiros. A chamada é assinada. Uma chamada forjada não entra. O evento chega em segundos, em vez de envelhecer até o job da madrugada.
- Pub/sub mais leve dentro do mesmo sistema. Redis Streams ou Redis Pub/Sub quando a carga não pede Kafka, e a fila já divide o resto da aplicação.
Tecnologias
A fila é uma decisão de durabilidade e de throughput. A assinatura é como o webhook prova que veio de quem enviou.
- Filas de mensagens e streaming. Kafka, SQS, RabbitMQ e Redis Streams, escolhidos conforme a durabilidade, a retenção e o throughput que a carga exige.
- Confirmação do offset. Consumidores Kafka confirmam o offset só depois de processar com sucesso, para uma queda não perder mensagens.
- Assinatura de webhook. HMAC na chamada. Um pedido que não verifica é recusado.
Como conduzimos
Uma situação técnica
O offset confirma antes da escrita. Uma queda perde a mensagem. Ou um webhook chega sem assinatura, e a chamada entra mesmo assim.
Como conduzimos
A gente confirma o offset depois que a escrita deu certo, e recusa o webhook que não verifica. Kafka, SQS, RabbitMQ ou Redis Streams, pela durabilidade e pelo throughput. A combinação sai do diagnóstico conforme carga, latência e retenção.
O que você recebe
Você sai com esse caminho rodando nos seus eventos, o código num repositório seu, e você decide se segue.
Dúvidas sobre filas e webhooks
Para fluxos de alto volume em tempo real usamos Kafka, com consumidores que confirmam o offset só depois de processar com sucesso, para uma queda não perder mensagens. Para pub/sub mais leve dentro do mesmo sistema, Redis Streams e Redis Pub/Sub custam menos e são mais simples de operar. Para sistemas de terceiros, preferimos webhooks com assinatura HMAC em vez de polling. A combinação sai do diagnóstico conforme carga, latência e retenção.
Para qualquer coisa que o usuário final percebe (notificação, status de pedido, saldo), sim. Webhook entrega em segundos em vez de deixar o dado envelhecer até o job das 3h da manhã. Para reconciliação contábil e relatórios fechados, batch ainda tem lugar.
Depende de durabilidade e throughput. SQS para workloads em AWS onde você quer o mínimo de operação. RabbitMQ quando precisa de roteamento por tópico ou confirmações por mensagem. Redis Streams quando a fila já divide cache com o resto da aplicação. A escolha entra no plano técnico conforme a carga real.
O que você recebe
- Uma solução funcionando nos seus dados
- O código é seu
- 2 a 5 semanas quando o dono e os arquivos já estão disponíveis
Vamos falar do seu caso
Fale com o laboratório
Escreve em poucas linhas o que o time faz hoje, e onde quebra. Respondemos no mesmo dia útil.
O que acontece depois
- Respondemos no mesmo dia útil
- Diagnóstico em 3-5 dias
- Solução funcionando em 1-3 semanas. Plano técnico nos últimos dias, com o trabalho feito.
Comece por aqui