Compra com cartão

Autorização síncrona, e um único evento consumido de forma independente por antifraude, notificação, cashback e analytics.

Este estudo de caso mostra o padrão mais comum de arquitetura orientada a eventos em sistemas de pagamento: uma decisão síncrona e crítica (autorizar ou não a compra) seguida de um evento único que múltiplos sistemas consomem de forma completamente independente, cada um preocupado com uma responsabilidade diferente.

O evento de domínio

A autorização em si — aprovar ou negar a compra no momento em que o cartão é passado — não é feita via Kafka. É uma chamada síncrona, com resposta em milissegundos, entre a maquininha (ou gateway de pagamento) e o autorizacao-service, que decide com base em saldo/limite disponível. Isso é intencional: o Capítulo 1 já explicou que comunicação request/response com resposta imediata não é o caso de uso do Kafka.

O que acontece depois da decisão síncrona é onde o Kafka entra: assim que a compra é aprovada, o autorizacao-service publica um evento CompraAutorizada — um fato que já aconteceu — e segue em frente, sem saber (nem precisar saber) quem vai reagir a isso.

{
  "eventId": "3a91f7c2-...",
  "cartaoId": "card_88213",
  "clienteId": "cli_50213",
  "valor": 15990,
  "estabelecimento": "Loja XYZ",
  "categoria": "varejo",
  "autorizadoEm": "2026-07-31T18:44:02Z"
}

Topologia de tópicos

Tópico e configuração

Item	Decisão
Tópico	`compras.autorizadas`
Key	`cartaoId`
Partitions	18
Replication factor	3
Retention	15 dias

Por que a key é `cartaoId`, não `clienteId`

Dica de entrevista

A escolha entre cartaoId e clienteId como key é um ótimo teste de entendimento de ordenação (Capítulo 4). Se um cliente tem múltiplos cartões e o requisito é apenas "processar compras do mesmo cartão em ordem" (ex.: para detectar uma sequência suspeita de compras no mesmo cartão em curto intervalo), a key correta é cartaoId. Se o requisito fosse consolidar comportamento do cliente como um todo, independente do cartão usado, clienteId seria a escolha — trocando ordenação por cartão por ordenação por cliente. Não existe resposta certa universal; depende de qual relação de ordem o domínio realmente precisa.

Consumidores independentes

Múltiplos Consumer Groups leem o mesmo tópico compras.autorizadas de forma independente.

antifraude-service: avalia a compra contra regras de risco (padrão de gasto, geolocalização, velocidade entre transações). Pode, em casos suspeitos, publicar um evento separado CompraSuspeita para acionar um bloqueio preventivo do cartão.
notificacao-service: envia push "Compra de R$ 159,90 aprovada em Loja XYZ".
cashback-service: calcula e credita o cashback aplicável, com base na categoria do estabelecimento.
analytics-service: alimenta um data warehouse para dashboards de gastos e modelos de recomendação.

Nenhum desses quatro consumers sabe da existência dos outros três. Uma lentidão no analytics-service (por exemplo, durante uma carga pesada de reprocessamento de relatórios) não atrasa a notificação push, que precisa ser quase instantânea para uma boa experiência do cliente.

Idempotência: nem todo consumer precisa do mesmo rigor

O nível de proteção contra duplicidade varia por consumer

Os quatro consumers deste evento têm exigências de idempotência muito diferentes entre si — um erro comum é aplicar o mesmo padrão de proteção (tabela de eventos processados) em todos, quando alguns já são naturalmente tolerantes à duplicidade.

Exigência de idempotência por consumer

Consumer	Efeito de duplicidade	Proteção necessária
`cashback-service`	Cashback creditado duas vezes — perda financeira direta	`eventId` + constraint de unicidade, obrigatório
`notificacao-service`	Cliente recebe duas notificações — irritante, não crítico	Nenhuma proteção especial necessária
`antifraude-service`	Reavalia a mesma compra duas vezes — trabalho redundante, não incorreto	Opcional, por eficiência, não por correção
`analytics-service`	Compra contada duas vezes na agregação — métricas infladas	Depende da consulta: agregações via upsert por `eventId` resolvem naturalmente

Retry e DLQ

O cashback-service, por lidar com valor financeiro direto, usa retry com backoff e DLQ (Capítulo 9): se a regra de cálculo de cashback falhar (ex.: tabela de categorias indisponível), a mensagem é reprocessada até 3 vezes antes de ir para compras.autorizadas.cashback.dlq, sem bloquear o crédito de cashback das compras seguintes.

Replay

Se a tabela de categorias de cashback for corrigida retroativamente (uma categoria que deveria dar 2% e estava configurada com 1%), o cashback-service pode fazer replay dos últimos 15 dias (dentro da retenção) para recalcular e creditar a diferença — desde que a lógica de crédito seja um upsert por eventId, evitando duplicar o cashback já creditado corretamente.

Observabilidade

O que cada time monitora

Time	Métrica prioritária
Cashback	Consumer lag e taxa de erro — atraso aqui vira reclamação de cliente sobre cashback não creditado
Notificação	Latência producer → consumer — o push precisa chegar em segundos para ter valor
Antifraude	Taxa de mensagens na DLQ — falhas de avaliação de risco não podem passar despercebidas
Analytics	Consumer lag agregado ao longo do dia — atraso aqui é tolerável em minutos, não segundos

Resumo

Este caso ilustra a diferença entre comunicação síncrona (a autorização em si, fora do Kafka) e assíncrona (tudo que reage à compra já aprovada). Um único evento, CompraAutorizada, é consumido por quatro sistemas com necessidades completamente diferentes de latência, idempotência e tolerância a falha — cada um configurado de acordo com sua própria criticidade, não com um padrão único aplicado indiscriminadamente a todos.

Capítulos relacionados