ADR: EventBridge vs Kafka/MSK para Processamento de Pedidos

O sistema de pedidos é o núcleo operacional da plataforma. Cada transição de estado de um pedido, criado, pago, separado, despachado, entregue, cancelado, precisa ser propagada de forma confiável para múltiplos consumidores downstream. Um erro nessa propagação pode resultar em cobrança dupla, estoque incorreto, falha de notificação ao cliente ou inconsistência no sistema de fraude.

A equipe de engenharia tem experiência sólida com AWS managed services e Lambda, mas não possui histórico operacional com Kafka. O time de plataforma tem dois engenheiros sênior dedicados à infraestrutura. A pressão de negócio é por time-to-market rápido, mas o CTO sinalizou que qualquer incidente de perda de pedido tem custo político alto.

As forças que moldam esta decisão são:

• Ordenação: pedidos individuais precisam ser processados em sequência. Um evento de order.cancelled não pode ser processado antes de order.paid para o mesmo orderId.
• Throughput: o volume atual não é extremo, mas os picos de Black Friday e datas sazonais exigem elasticidade real.
• Replay: a equipe de analytics e o time de fraude precisam reprocessar eventos históricos quando modelos mudam ou bugs são corrigidos.
• Carga operacional: com um time pequeno, cada hora gasta em tuning de brokers é uma hora a menos em features.
• Custo: MSK tem custo fixo de infraestrutura independente de uso; EventBridge cobra por evento publicado.
• Integração com o ecossistema AWS: o stack existente é 100% AWS; integrações nativas reduzem código de cola.

A tentação comum é tratar EventBridge como "Kafka gerenciado mais simples". Essa analogia é perigosa. EventBridge é um event router baseado em regras, ele roteia eventos de fontes para destinos com base em padrões de conteúdo. Kafka (e MSK) é um log distribuído de commits: ele armazena eventos de forma durável, ordenada e permite múltiplos consumidores independentes lerem no seu próprio ritmo.

Essas diferenças têm implicações concretas:

Ordenação: EventBridge não garante ordenação entre eventos. Para um sistema de pedidos onde a sequência created → paid → shipped é semanticamente crítica, isso exige que os consumidores implementem lógica de ordenação própria ou que a aplicação tolere eventos fora de ordem. MSK com particionamento por orderId garante ordenação dentro da partição, o que é exatamente o que precisamos.

Replay: EventBridge Archive permite replay de eventos, mas com limitações, o replay é para o mesmo destino e não suporta filtragem granular por consumidor. MSK retém o log por período configurável (dias a semanas) e qualquer consumer group pode reposicionar seu offset para qualquer ponto no tempo, independentemente dos outros. Para o time de analytics que precisa reprocessar 30 dias de eventos sem afetar o consumer de pagamentos, MSK é estruturalmente superior.

Fan-out e acoplamento: EventBridge brilha no fan-out desacoplado, você adiciona uma nova regra e um novo destino sem tocar no produtor. MSK requer que novos consumidores criem seus próprios consumer groups, o que é igualmente desacoplado mas exige mais configuração inicial.

Throughput e latência: EventBridge tem throughput padrão de 10.000 eventos/segundo por região (com soft limits ajustáveis via suporte), latência tipicamente abaixo de 1 segundo mas sem SLA de latência publicado. MSK suporta throughput de centenas de MB/s com latência de milissegundos em configurações adequadas. Para o volume atual do sistema, ambos são suficientes, mas MSK tem headroom muito maior.

O ponto central é: EventBridge é a escolha certa quando o problema é roteamento e integração de serviços; MSK é a escolha certa quando o problema é streaming de dados com ordenação, replay e múltiplos consumidores independentes. Processamento de pedidos é o segundo caso.

Estratégia de particionamento: A chave de partição deve ser o orderId. Isso garante que todos os eventos de um pedido específico sejam escritos na mesma partição e, portanto, consumidos em ordem. O número inicial de partições para o tópico orders deve ser calculado com base no throughput de pico esperado dividido pelo throughput por partição sustentável (tipicamente 1-10 MB/s dependendo do tamanho da mensagem e configuração do broker). Para o volume estimado, 12 partições é um ponto de partida razoável, permite até 12 instâncias paralelas de um consumer group sem rebalancing.

Retenção e replay: Configurar retention.ms para 604800000 (7 dias) no tópico principal. Para o tópico de pedidos, considerar 30 dias dado o requisito de reprocessamento do time de analytics. O replay é operacionalizado via reset de offset do consumer group, o time deve ter runbooks documentados para essa operação, incluindo como pausar o consumer de produção antes do replay para evitar processamento duplicado não intencional.

Consumer criticality tiers: Nem todos os consumers têm o mesmo SLA. Pagamentos e estoque são críticos, devem rodar em ECS/Fargate com auto-scaling baseado em consumer lag (métrica EstimatedMaxTimeLag no CloudWatch MSK). Notificações e analytics podem usar Lambda via MSK Event Source Mapping, aceitando latência maior em troca de menor custo operacional.

Dead Letter Queue: Cada consumer deve ter uma DLQ (SQS) para mensagens que falham após N tentativas. O schema de retry deve ser exponential backoff com jitter. Mensagens na DLQ devem gerar alertas no CloudWatch e ter processo de reprocessamento manual documentado.

Risco de rebalancing: Em consumers ECS, o rebalancing do Kafka pode causar pausas de processamento de segundos a dezenas de segundos dependendo do tamanho do grupo e da estratégia de rebalancing. Configurar partition.assignment.strategy=CooperativeStickyAssignor para minimizar o impacto. Monitorar RebalanceLatency e alertar se exceder thresholds aceitáveis.

MSK Serverless vs Provisioned: MSK Serverless simplifica o início, mas tem limitações: throughput máximo de 200 MB/s de escrita e 400 MB/s de leitura por cluster, sem controle de número de partições (gerenciado automaticamente), e custo por unidade de capacidade que pode ser mais alto que Provisioned em volumes altos. A migração para Provisioned deve ser planejada quando o volume mensal de dados processados tornar o custo por unidade de capacidade desfavorável, tipicamente acima de alguns TB/mês (estimativa).