Quais são as semânticas de entrega do Kafka (at-least-once, exactly-once)?

Question

Accepted Answer

O Kafka suporta diferentes **garantias de entrega** — **at-most-once**, **at-least-once** e **exactly-once** — que determinam se as mensagens podem ser perdidas ou duplicadas. Entender essas garantias e como alcançá-las é importante para construir sistemas confiáveis.

## As três semânticas de entrega

```text
AT-MOST-ONCE → messages may be LOST but never duplicated:
  → commit offset BEFORE processing → if processing fails, the message is skipped (lost)
  → for: when occasional loss is acceptable and duplicates are not (rare)
AT-LEAST-ONCE → messages are never lost but may be DUPLICATED:
  → commit offset AFTER processing → if a crash occurs before commit, the message is
    reprocessed (duplicate) → requires IDEMPOTENT processing
  → the common default; safe (no loss) but handle duplicates
EXACTLY-ONCE → each message is processed exactly once (no loss, no duplicates):
  → the strongest, but hardest; requires Kafka transactions + idempotent producers
```

## Alcançando as garantias

```text
→ AT-LEAST-ONCE → process then commit; make consumers IDEMPOTENT (handle duplicates safely
  via dedup keys, idempotent operations) — practical and common
→ EXACTLY-ONCE → Kafka's transactional API + idempotent producer (enable.idempotence) →
  produce + commit offsets atomically (exactly-once within Kafka, e.g. Kafka Streams)
  ⚠️ exactly-once is complex and has overhead; often AT-LEAST-ONCE + idempotency is simpler
    and sufficient
```

## Orientação prática

```text
✓ Most systems use AT-LEAST-ONCE + idempotent processing (simple, reliable)
✓ Use EXACTLY-ONCE when duplicates are truly unacceptable AND idempotency is hard
✓ Producer acks (acks=all) → durability (don't lose on the produce side)
→ understand the trade-offs; design for the guarantee your use case needs
```

## Por que isso importa

Entender as semânticas de entrega do Kafka é valioso porque **as garantias de entrega determinam confiabilidade** (se as mensagens podem ser perdidas ou duplicadas), então compreendê-las é importante para construir sistemas confiáveis.

A escolha das semânticas de entrega afeta diretamente a correção.

Entender as **três semânticas de entrega** — **at-most-once** (mensagens podem ser perdidas, mas não duplicadas, confirmando o offset antes do processamento — para quando perda ocasional é aceitável), **at-least-once** (mensagens nunca perdidas, mas possivelmente duplicadas, confirmando após o processamento, exigindo processamento idempotente — o padrão seguro e comum), e **exactly-once** (cada mensagem processada exatamente uma vez, o mais forte mas mais difícil, exigindo transações e produtores idempotentes) — é essencial para entender os trade-offs de confiabilidade.

Entender **como alcançar as garantias** — at-least-once processando e depois confirmando, tornando os consumidores **idempotentes** (tratando duplicatas via chaves de dedup e operações idempotentes — prático e comum), e exactly-once via API transacional do Kafka e produtor idempotente (produzindo e confirmando offsets atomicamente), com a ressalva importante de que exactly-once é complexo com overhead enquanto **at-least-once mais idempotência é frequentemente mais simples e suficiente** — reflete a abordagem prática.

Entender a **orientação prática** — que a maioria dos sistemas usa at-least-once com processamento idempotente (simples e confiável), usando exactly-once apenas quando duplicatas são verdadeiramente inaceitáveis e idempotência é difícil, e usando acks de produtor para durabilidade — reflete julgamento de design sólido.

A visão chave é que as semânticas de entrega envolvem trade-offs (perda vs duplicatas vs complexidade), e a escolha comum e prática é at-least-once com idempotência, que se conecta à importância mais ampla de idempotência em sistemas distribuídos.

Como as garantias de entrega determinam se as mensagens podem ser perdidas ou duplicadas (afetando diretamente a confiabilidade) e entender as semânticas, como alcançá-las (especialmente at-least-once com idempotência como padrão prático) e os trade-offs é importante para construir sistemas confiáveis, entender as semânticas de entrega do Kafka é conhecimento Kafka valioso e praticamente importante — central para confiabilidade, importante para projetar sistemas com as garantias corretas (comumente at-least-once com idempotência) e refletindo o entendimento necessário para construir sistemas confiáveis baseados em Kafka.