Exactly-Once Delivery Is Mostly Marketing

Distributed systems promise many things.

High availability. Horizontal scale. Event-driven architecture.

And sometimes:

Exactly-once delivery.

That promise is usually misunderstood.

1. What Exactly-Once Actually Means

“Exactly-once” can refer to multiple things:

• Message delivered exactly once
• Message processed exactly once
• Side effects applied exactly once

These are not equivalent.

Delivery guarantees do not equal effect guarantees.

2. Why It’s Almost Impossible

In distributed systems, failures are indistinguishable from delays.

If a consumer processes a message and crashes before acknowledging, what happened?

• Did it process?
• Did it commit side effects?
• Did it persist state?

The broker cannot know.

Therefore it must retry.

Retry implies potential duplicate delivery.

This is fundamental. Not implementation-specific.

3. The Layer Confusion Problem

Many systems advertise exactly-once at a specific layer.

For example:

• Kafka: exactly-once semantics (EOS)
• Database: transactional writes
• Message broker: idempotent producer

But these guarantees are scoped.

Kafka EOS ensures:

• No duplicate writes to Kafka logs
• Atomic commit of consumed + produced messages

It does not guarantee:

• Your database side effects are idempotent
• Your external API calls are deduplicated
• Your Redis writes are unique

4. Redis, Kafka and the Fine Print

Consider this flow:

1. Consume event
2. Update database
3. Write to Redis
4. Commit offset

If crash happens after step 3 but before step 4:

• Offset not committed
• Event will be replayed
• Database update may execute again
• Redis write may execute again

Even with Kafka EOS, your external side effects remain vulnerable.

Exactly-once inside Kafka. At-least-once outside.

5. The Real Strategy: Idempotency

Production systems do not rely on exactly-once.

They rely on idempotency.

Idempotency means:

Repeating the same operation does not change the outcome.

Example:

INSERT INTO payments (id, amount)
VALUES (:event_id, :amount)
ON CONFLICT (id) DO NOTHING;

Duplicate event? No duplicate payment.

This is correctness through design.

6. Designing for Correctness

1. Use Idempotency Keys

Every external request should carry a unique identifier.

2. Make Side Effects Idempotent

• UPSERT instead of INSERT
• SET instead of INCREMENT when possible
• Compare-and-set operations

3. Separate Processing from Effects

Store event processing result first. Apply side effects after durable state.

4. Accept At-Least-Once Reality

Distributed systems naturally converge to:

At-least-once delivery + idempotent processing.

7. Conclusion

Exactly-once delivery is a scoped optimization.

It is not a universal guarantee.

Real systems achieve correctness through:

• Bounded resources
• Backpressure
• Idempotent side effects
• Clear failure semantics

This series was never about Redis.

It was about understanding where systems actually break.