❌ Exactly-Once Processing Doesn’t Exist

❌ Exactly-Once Processing Doesn’t Exist

Even with Kafka (and especially not in your Spring Boot app)

SEO keywords: exactly once processing myth, Kafka exactly once, Spring Boot Kafka transactions, distributed systems guarantees, message processing semantics

😌 The Promise Everyone Wants to Believe

“Kafka supports exactly-once semantics.”

This sentence sounds comforting.

It sells architectures.
It calms managers.
It gives teams confidence.

And it is dangerously incomplete.

🧠 What “Exactly-Once” Actually Means (In Marketing)

In practice, “exactly-once” usually means:

Exactly once under perfect conditions,
inside Kafka,
for offsets and records,
not for your business logic.

Your system is larger than Kafka.

That’s where the guarantee collapses.

💥 The Unavoidable Problem

Distributed systems cannot know whether:

• Your DB committed
• Your API call succeeded
• Your cache updated
• Your email was sent

Kafka only knows:

• Did I send the record?
• Did you ACK the offset?

Everything else is outside its control.

🧨 Where Exactly-Once Breaks (Every Time)

1️⃣ JVM Crashes at the Wrong Moment

DB commit succeeds  
JVM crashes  
Offset not committed

Result: message replay → duplicate side effects.

Reverse it?

Offset committed  
DB commit fails

Result: lost message.

You must choose one.

2️⃣ Network Partitions Lie to Everyone

ACK lost?
Was it processed?
Was it not?

Kafka cannot tell.
Neither can you.

So it retries.

Duplicates are inevitable.

3️⃣ External Systems Are Not Transactional

Kafka transactions do not include:

• REST APIs
• Email systems
• Payment gateways
• Search indexes

Once you step outside Kafka:
👉 exactly-once is gone.

⚠️ Spring Boot Example That “Looks Exactly-Once”

@Transactional
@KafkaListener(topics = "orders")
public void handle(OrderEvent event) {
    repository.save(event.toEntity());
}

Feels safe.

Get Lakshika’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

But:

• DB and Kafka are separate systems
• No shared transaction coordinator
• Crash window always exists

This is at-least-once with hope.

🧠 Why Vendors Still Say “Exactly-Once”

Because:

• It’s technically true inside Kafka
• It’s marketable
• It reduces fear
• It sounds final

But production systems are end-to-end, not broker-local.

💣 The Dangerous Outcome of Believing the Myth

Teams who believe in exactly-once:

• Skip idempotency
• Skip deduplication
• ACK early
• Ignore reprocessing

And when failure happens:
👉 Data corruption, not retries.

✅ The Only Model That Actually Works

🔹 At-Least-Once + Idempotency

Accept:

• Duplicates will happen
• Replays will occur
• Failures are normal

Design so:

• Reprocessing is safe
• Side effects are idempotent
• State transitions are guarded

This model survives reality.

🧠 The Mental Shift That Changes Everything

Stop asking:

“How do we guarantee exactly-once?”

Start asking:

“How do we survive reprocessing?”

That’s the real engineering question.

🚀 Final Takeaway (This Line Gets Quoted)

Exactly-once is a comforting story.
At-least-once is the truth.
Idempotency is the solution.