Skip to content
ROOT
STUB

Delivery Semantics

The pattern: three guarantees a message system can offer between producer and consumer. At-most-once (deliver or drop; never duplicate; lossy). At-least-once (deliver eventually; may duplicate; needs idempotent consumer). Exactly-once-ish (a coordinated dance: idempotent producer + transactional broker + idempotent consumer). The third is a marketing claim with asterisks.

The trade-off: safety vs. throughput vs. latency. At-most-once is fast and lossy. At-least-once is reliable and requires consumer-side idempotency. Exactly-once-ish costs throughput (transactions) and latency (commit barriers). Most production systems pick at-least-once + idempotent consumer — the “exactly-once-ish” version is a careful engineered claim, not a default.

[Deepen Year 2 Phase 8; reinforced Year 3 Phase 16 with Flink + Iceberg sink transactions.]

  • Idempotency — the consumer-side mechanism that makes at-least-once survivable.
  • Backpressure — slow consumers and at-least-once is exactly when queues melt without flow control.
  • Two-phase commit vs. sagas — exactly-once-ish across services is a saga problem, not a queue problem.
  • Stream processing — Flink’s checkpoints + Iceberg’s atomic commits are how exactly-once becomes credible.
  • Append-only log — the substrate Kafka/Redpanda use to make replay deterministic.

First touched in Year 2 Phase 8; reinforced in Year 3 Phase 16 when Flink + Iceberg sinks make exactly-once-ish concrete.