MessagingExpertplaybookPart 4 of 4 in Kafka Production Playbook

Exactly-Once Semantics: The Mathematical Impossibility

Exactly-once is a lie. Learn the Two Generals' Problem and how systems like Kafka achieve 'Effectively' Exactly-Once.

Sachin Sarawgi•April 20, 2026•1 min read•1 minute lesson
#exactly-once#kafka#distributed-systems#consistency
On This PageOpen
Back to top
Recommended Prerequisites
Distributed Transactions Part 5: Idempotency

Exactly-Once: The Mathematical Impossibility

Exactly-once processing is impossible in a distributed system because you cannot guarantee the delivery of the (acknowledgement) over an unreliable network.

1. The Two Generals' Problem

Two generals must agree on an attack time over an unreliable communication channel. It is mathematically proven that they can never reach agreement with certainty.

2. Effectively Exactly-Once

We simulate exactly-once via Idempotency.

  • You do send the message twice, but the consumer detects the duplicate ID and ignores the second attempt.

Conclusion: Exactly-once is a developer abstraction. The infrastructure underneath is always doing "At-least-once" delivery + "Idempotent" processing.

Practical engineering notes

Get the next backend guide in your inbox

One useful note when a new deep dive is published: system design tradeoffs, Java production lessons, Kafka debugging, database patterns, and AI infrastructure.

No spam. Just practical notes you can use at work.

Sachin Sarawgi

Written by

Sachin Sarawgi

Engineering Manager and backend engineer with 10+ years building distributed systems across fintech, enterprise SaaS, and startups. CodeSprintPro is where I write practical guides on system design, Java, Kafka, databases, AI infrastructure, and production reliability.

LinkedInGitHubMediumMore articles

Share this lesson

Share on XShare on LinkedIn

Continue Series

Kafka Production Playbook

Lesson 4 of 4 in this learning sequence.

1

Advanced

Change Data Capture with Debezium: Real-Time Data Synchronization Patterns

Change Data Capture (CDC) is one of those techniques that, once you understand it, you see it everywhere. The pattern: instead of your application explicitly publishing events when data changes, let the database engine i…

2

Advanced

Distributed Transactions Part 4: The Transactional Outbox

Part 4: The Transactional Outbox The Dual Write Problem occurs when you update your DB and then try to send an event to Kafka. If the Kafka send fails, your DB and downstream systems are out of sync. 1. The Solution Writ…

3

Advanced

Event-Driven Architecture: CQRS and Event Sourcing in Practice

Traditional CRUD systems store current state. Event-driven systems store the history of state changes. This single difference is more profound than it first appears: instead of asking "what is the current status of order…

4

Expert

Exactly-Once Semantics: The Mathematical Impossibility

Exactly-Once: The Mathematical Impossibility Exactly-once processing is impossible in a distributed system because you cannot guarantee the delivery of the (acknowledgement) over an unreliable network. 1. The Two General…

Keep Learning

Move through the archive without losing the thread.

Previous Article

Hardware-Aware Programming: Optimizing for Modern CPUs

Hardware-Aware Programming In high-frequency environments, the efficiency of your code is dictated by the hardware. 1. NUMA Nodes Modern servers have multiple CPUs with local RAM (Non-Uniform Memory Access). If your thre…

Java1 min readExpert

Next Article

Distributed Snapshots: Chandy-Lamport Algorithm

Distributed Snapshots: Chandy-Lamport How do you take a "global photo" of a system where every node has a different time and no central master? 1. The Problem You need to save the state of a system for debugging or check…

System Design2 min readExpert

Related Articles

More deep dives chosen from shared tags, category overlap, and reading difficulty.

MessagingAdvanced

Distributed Transactions Part 4: The Transactional Outbox

Part 4: The Transactional Outbox The Dual Write Problem occurs when you update your DB and then try to send an event to Kafka. If the Kafka send fails, your DB and downstream systems are out of sync. 1. The Solution Writ…

Apr 20, 20261 min read
Deep DiveKafka Production Playbook
#kafka#outbox-pattern#cdc
MessagingAdvanced

The Transactional Outbox Pattern: Reliability in Microservices

The Transactional Outbox Pattern In a microservice, you often need to save data to a database (e.g., Order) and send an event to Kafka (e.g., OrderCreated). If the DB write succeeds but the Kafka send fails, your system…

Apr 20, 20262 min read
Deep DiveBackend Systems Mastery
#microservices#kafka#distributed-systems
MessagingAdvanced

Kafka Consumer Rebalancing: The Senior Engineer's Playbook

Kafka Consumer Rebalancing: Surviving the Storm Consumer Group Rebalancing is one of the most common causes of latency spikes in Kafka-based systems. During a rebalance, consumers stop processing messages to redistribute…

Apr 20, 20262 min read
Playbook
#kafka#messaging#performance
MessagingAdvanced

Kafka Internals: The Storage Layer, Zero-Copy, and High Throughput

Kafka Internals: The Quest for 10M msg/sec Apache Kafka is often described as a distributed streaming platform, but its heart is a Distributed Commit Log. Its ability to handle massive throughput with sub-millisecond lat…

Apr 20, 20263 min read
Deep DiveKafka & Event-Driven Mastery
#kafka#internals#zero-copy

More in Messaging

Category-based suggestions if you want to stay in the same domain.

MessagingIntermediate

Kafka Consumer Groups Explained: Scaling Your Message Consumption

Kafka Consumer Groups Explained In a production environment, a single consumer is often not enough to handle the volume of data flowing through a Kafka topic. Consumer Groups are the primary mechanism for scaling consump…

Apr 20, 20262 min read
Deep DiveKafka & Event-Driven Mastery
#kafka#messaging#distributed systems
← Back to all articles