garantías de entrega en kafka

introducción

en sistemas event‑driven los mensajes pueden perderse o duplicarse por fallas de red y reintentos. kafka ofrece distintos niveles de entrega: at‑most‑once, at‑least‑once y exactly‑once.

elegir la garantía correcta es un balance entre costo y riesgo: logging tolera pérdidas; pagos requieren evitar duplicados; analítica batch puede preferir reintentos.

comparativa rápida

garantía	llega siempre	puede duplicarse	puede perderse
at‑most‑once	✘ no	✘ no	✔ sí
at‑least‑once	✔ sí	✔ sí	✘ no
exactly‑once	✔ sí	✘ no	✘ no

at‑most‑once

prioriza velocidad: el producer no reintenta ni espera acks fuertes. si hay fallo de red, el mensaje puede perderse, pero nunca se procesa dos veces.

At-most-once — falla de red, evento se pierde — falla — se puede perder.

at‑least‑once

garantiza llegada reintentando. consecuencia: puede haber duplicados. se mitiga con idempotencia en producer y/o deduplicación en el consumidor.

At-least-once (producer) — duplicados por reintento — producer — duplicados por reintentos.

At-least-once (consumer) — happy path — consumer — happy path.

At-least-once (consumer) — procesa dos veces — consumer — puede procesar dos veces.

exactly‑once (EOS)

evita duplicados y pérdidas con idempotencia y transacciones. requiere: enable.idempotence=true, acks=all, retries altos, transactional.id y consumidores con isolation.level=read_committed.

Exactly-once: flujo con commit de transacción — producer transaccional + consumer read_committed.

Exactly-once — diagrama detallado — diagrama paso a paso.

configs útiles

// Producer idempotente
enable.idempotence=true
acks=all
retries=2147483647
max.in.flight.requests.per.connection=5

// Producer transaccional (EOS)
transactional.id=payments-tx-01

// Consumer que ignora mensajes no confirmados
isolation.level=read_committed

¿cuál usar?

regla práctica: logs/telemetría → at‑most‑once; integraciones críticas → at‑least‑once con idempotencia; pagos/contabilidad → exactly‑once (o idempotencia fuerte de negocio).