A arquitetura event-driven é um modelo em que os sistemas se comunicam por eventos assíncronos — pedido criado, pagamento aprovado, estoque alterado — em vez de chamadas diretas e síncronas entre serviços. No varejo, a regra prática é simples: use Kafka quando precisar de alto volume, streaming contínuo e reprocessamento histórico de eventos; use RabbitMQ quando precisar de filas de trabalho, roteamento de tarefas e entrega confiável com baixa latência.
O que é arquitetura event-driven e por que o varejo precisa dela
Em uma operação de varejo, dezenas de sistemas precisam reagir ao mesmo fato: o ERP, o e-commerce, o WMS, o antifraude, o CRM e o marketing. Quando tudo depende de chamadas síncronas ponto a ponto, uma indisponibilidade em um sistema derruba os demais e a operação trava justamente no pico de venda.
Na arquitetura event-driven, quem produz o evento não conhece — nem espera — quem consome. O produtor publica "pedido aprovado" uma única vez e cada consumidor reage no seu ritmo. Isso desacopla os sistemas, absorve picos de Black Friday e permite adicionar novos consumidores sem reescrever o produtor.
Kafka vs RabbitMQ: quando usar cada um
Os dois resolvem mensageria assíncrona, mas foram desenhados para problemas diferentes. Escolher errado gera custo de infraestrutura e retrabalho.
Prefira Kafka quando:
- O volume é alto e contínuo (cliques, page views, eventos de tracking, telemetria de loja);
- Você precisa reprocessar o histórico — reconstruir um relatório ou realimentar um novo sistema a partir de eventos antigos;
- Vários times consomem o mesmo fluxo de forma independente, cada um no seu offset.
Prefira RabbitMQ quando:
- O caso é distribuição de tarefas (enviar e-mail, gerar nota fiscal, chamar gateway de pagamento);
- Você precisa de roteamento sofisticado por tipo de mensagem e baixa latência por item;
- O evento é consumido uma vez e descartado, sem necessidade de guardar histórico.
Na prática, muitos varejos usam os dois: Kafka como espinha dorsal de eventos e RabbitMQ para orquestrar tarefas específicas. Se a dúvida real é entre montar um broker próprio ou adotar uma plataforma de integração gerenciada, vale comparar com o cenário de MuleSoft vale a pena? Custo, alternativas e quando o iPaaS se paga.
Os padrões que evitam pedido duplicado e estoque furado
Mensageria assíncrona sem disciplina de engenharia é uma fábrica de inconsistência: pedido em duplicidade, estoque negativo, cobrança repetida. Os padrões que tornam o evento confiável são:
- Idempotência: processar o mesmo evento duas vezes produz o mesmo resultado, sem duplicar o pedido;
- Retry com backoff: reprocessa falhas temporárias com espera crescente, sem derrubar o consumidor;
- Dead Letter Queue (DLQ): isola mensagens que falham de forma persistente para análise, em vez de bloquear a fila;
- Outbox pattern: garante que o evento só seja publicado se a transação no banco foi confirmada, eliminando o "gravei mas não publiquei";
- Reconciliação: cruza periodicamente os sistemas para detectar e corrigir divergências que escaparam.
Como a CCX faz
A CCX Company já entregou mais de 200 projetos e integrações enterprise no Brasil e na LATAM, e trata event-driven como parte da nossa prática de integração de sistemas da CCX — não como um experimento. Ligamos Kafka e RabbitMQ a plataformas como SAP CPI/BTP, MuleSoft Anypoint, VTEX, Salesforce e TOTVS Protheus, sempre com os padrões de confiabilidade embutidos.
Nosso caminho típico de implementação segue estas etapas:
- Mapear os eventos de negócio reais (pedido, pagamento, estoque, devolução) e quem produz e consome cada um;
- Escolher o broker por caso de uso — Kafka para streaming, RabbitMQ para tarefas — em vez de padronizar um só na marra;
- Desenhar contratos de evento versionados, para que novos consumidores entrem sem quebrar os antigos;
- Implementar idempotência, retry com backoff, DLQ e Outbox em cada consumidor crítico;
- Instrumentar observabilidade e reconciliação para provar que nenhum evento se perdeu;
- Rodar carga de pico (Black Friday) antes de ir para produção.
Quanto custa e quando vale a pena
Ser honesto sobre custo é parte do projeto: o valor depende de escopo — número de sistemas, volume de eventos e SLA exigido. Para operações que precisam de mão de obra contínua, squads dedicados começam em R$ 35 mil/mês; projetos de plataforma como Salesforce Commerce começam em R$ 250 mil, com licenças cobradas à parte pelo fabricante.
Event-driven não é para todo mundo. Se a operação tem poucos sistemas e volume baixo, uma integração síncrona bem-feita pode bastar. O modelo se paga quando há pico sazonal severo, muitos consumidores do mesmo dado ou necessidade de reprocessar histórico — casos em que o acoplamento síncrono vira gargalo e risco.
Perguntas frequentes
Kafka ou RabbitMQ: qual é melhor para e-commerce?
Não há um vencedor absoluto. Kafka é melhor para fluxos de alto volume e reprocessamento (tracking, telemetria, analytics); RabbitMQ é melhor para filas de tarefas e roteamento com baixa latência (e-mail, nota fiscal, pagamento). Muitas operações de varejo usam os dois juntos, cada um no seu ponto forte.
A arquitetura event-driven elimina o risco de pedido duplicado?
Não por si só — a entrega assíncrona pode até aumentar o risco se for mal implementada. O que elimina a duplicidade é a combinação de idempotência, Outbox pattern e reconciliação. Sem esses padrões, o broker apenas espalha o problema mais rápido.
Quanto tempo leva para implementar event-driven no varejo?
Depende de escopo, mas o primeiro passo é rápido: a CCX oferece um diagnóstico gratuito de 60 minutos com TCO e cronograma por fase em até 7 dias. A partir daí, o prazo varia conforme o número de sistemas e o volume de eventos envolvidos.