Exactly-once delivery
Exactly-once delivery is a messaging or processing guarantee that each message or input produces its intended effect once, without loss or duplicate effects, despite retries or failures.
Kafka for Architects
Exactly-once delivery is a processing guarantee in which each record's effect is applied once despite retries or failures.
- How it is used
- Protects Kafka read-process-write pipelines from duplicate or missing outputs during retries and failures.
- How deep it goes
- Details atomic output, state, and offset commits and names the Kafka Streams setting, without a full client implementation walkthrough.
- Examples
- Illustrates one order generating shipment, billing, and inventory events, where duplicates or omissions cause downstream discrepancies.
- What you can do after
- Operate/configure it in Kafka Streams with processing.guarantee set to EXACTLY_ONCE_V2.
Read how Kafka for Architects explains exactly-once delivery →
Kafka Streams in Action, Second Edition
Exactly-once semantics is a message-processing guarantee that each input record's effects are applied once without duplicate results despite retries or failures.
- How it is used
- Guarantees reliable Kafka record delivery when retries, consumer failures, or transactional processing make duplicates or loss unacceptable.
- How deep it goes
- Distinguishes delivery guarantees and explains idempotent, transactional, offset, and isolation configurations without showing transaction implementation code.
- Examples
- Uses producer retries, aborted transactions, per-partition idempotence, and atomic publication across multiple topics as concrete cases.
- What you can do after
- Configure KafkaProducer transactions, assign unique transactional IDs, and consume transactional topics using read_committed isolation.
Read how Kafka Streams in Action, Second Edition explains exactly-once delivery →
Think Distributed Systems
A message-delivery guarantee in which each sent message is delivered exactly one time.
- How it is used
- Clarifies delivery guarantees and redirects reliable system design toward exactly-once processing semantics.
- How deep it goes
- Derives impossibility from sender choices and failure uncertainty, then explains equivalence, idempotence, and end-to-end requirements.
- Examples
- Uses duplicate-suppression algorithms, airline-ticket payment retries, reservation identifiers, and Stripe-style idempotency keys.
- What you can do after
- Evaluate delivery claims and design retries around idempotent processing rather than assuming literal exactly-once delivery.
Read how Think Distributed Systems explains exactly-once delivery →
Apache Kafka in Action
Exactly-once semantics guarantee that each input message produces one durable effect in the destination despite retries or failures.
- How it is used
- Prevents retries after uncertain ACKs from turning one intended write into duplicate durable messages or effects.
- How deep it goes
- Explains producer sequence IDs and works through database and Kafka transaction patterns, while leaving transaction-coordinator internals to a summary.
- Examples
- Uses a lost-ACK banking transaction, PostgreSQL write patterns, and a Python transactional producer updating two balances.
- What you can do after
- Operate/configure it with idempotent producers, and apply transactional offset handling when processing Kafka messages into Kafka or a database.
Read how Apache Kafka in Action explains exactly-once delivery →
Architecting an Apache Iceberg Lakehouse
Exactly-once semantics guarantee that each input record contributes its intended processing effect no more than once despite retries or failures.
- How it is used
- Builds reliable streaming and batch ingestion pipelines where retries, restarts, duplicates, and partial table writes must be controlled.
- How deep it goes
- Explains replayability, checkpointing, two-phase commits, atomic snapshots, state recovery, and commit-frequency tradeoffs without low-level protocol detail.
- Examples
- Demonstrates Kafka-to-Iceberg Flink SQL, checkpoint-based retries, and Spark Structured Streaming with Iceberg checkpoints.
- What you can do after
- Build it from scratch with Flink or Spark, configuring replayable sources, checkpoints, transactional sinks, and recovery-aware streaming commits.
Read how Architecting an Apache Iceberg Lakehouse explains exactly-once delivery →
Akka in Action, Second Edition
Effectively-once delivery is a processing guarantee that combines at-least-once processing with deduplication so that duplicate processing has one externally visible effect.
- How it is used
- Guarantees one externally visible effect when retries or crashes cause duplicate processing in Kafka streams and journal projections.
- How deep it goes
- Explains retry behavior, deduplication, APIs, configuration, identity constraints, and performance tradeoffs without developing transaction internals.
- Examples
- Uses an A-to-B-to-C retry pipeline, transactional Kafka source and sink, and an event-to-database projection.
- What you can do after
- Apply it via Akka Transactional or Akka projections to process Kafka or journal events with deduplicated effects.
Read how Akka in Action, Second Edition explains exactly-once delivery →
Related concepts
- idempotencycontrasts with · Idempotency is the property of an operation whereby repeating it has the same effective result or externally observable effect as performing it once.
- deduplicationaddressed by · Deduplication is the identification and removal, suppression, or consolidation of repeated representations of the same logical item, event, or operation according to a defined criterion.
- mathematical equivalenceuses · Mathematical equivalence is a relation in which different expressions or representations have the same value or meaning under a specified interpretation.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.