What Happens When You Miss an Eddy

Opening Scene

A guide who misses an eddy — a calm pocket of water worth catching for a rest or a maneuver — has real choices about what happens next. Paddle hard and try to catch it anyway, even if that means passing it twice. Let it go and catch the next one instead. Or, in rare cases, just accept the miss and keep moving, treating it as acceptable loss. None of these is universally correct; which one makes sense depends entirely on how much that specific eddy actually mattered.

Streaming systems face the exact same decision, formalized as delivery semantics, for every single event.

In Plain English

Delivery semantics describe the guarantee a streaming system makes about whether an event gets processed. At-most-once means an event might be lost but will never be processed twice. At-least-once means an event will never be lost but might be processed more than once. Exactly-once means an event is processed once and only once — the ideal in principle, and the hardest and most expensive guarantee to actually deliver in practice.

The Old Way

Early streaming systems often defaulted to at-most-once semantics almost by accident — the simplest thing to implement, prioritizing throughput and simplicity over completeness. This was fine for use cases where an occasional lost event genuinely didn’t matter (a dropped sensor reading among thousands), and a real problem for use cases where it did (a dropped financial transaction).

At-least-once became a common improvement, trading the risk of duplicate processing for the assurance that nothing gets silently lost. But duplicates create their own problem: a payment processed twice, a counter incremented twice for the same event — without additional handling, at-least-once alone doesn’t fully solve the reliability question either.

What’s Changing (and Why AI Is the Reason)

Idempotency, covered in more depth for pipelines elsewhere on this site, is the practical answer to at-least-once’s duplicate risk. Designing event handling so that processing the same event twice produces the same result as processing it once — the same idea this site’s data-pipelines-etl topic covered for batch pipelines — is what makes at-least-once semantics genuinely safe to build on for most use cases.
True exactly-once semantics are becoming more practically achievable, not just theoretically desirable. Modern streaming platforms increasingly offer built-in support for exactly-once processing in specific, well-defined scenarios, narrowing the gap between the ideal guarantee and what’s actually deployable without heroic custom engineering.
AI is helping identify which delivery guarantee a given use case actually needs. Rather than defaulting to the strictest, most expensive guarantee out of caution, AI-assisted analysis of a use case’s actual sensitivity to loss or duplication can inform a deliberately chosen, appropriately-scoped guarantee — avoiding both under-engineering critical paths and over-engineering ones that don’t need it.

The Metaphor, Fully Extended

River Element	Delivery Semantics Concept
Missing an eddy and letting it go entirely	At-most-once: the event might be lost, never duplicated
Circling back and possibly catching the same eddy twice	At-least-once: the event won’t be lost, but might be processed twice
A guide who catches every eddy exactly once, no misses, no repeats	Exactly-once: the ideal, hardest guarantee to deliver
Treating a repeated eddy visit as identical to visiting once	Idempotent event handling, making duplicates harmless
A trip planner deciding in advance how much a specific eddy actually matters	Deliberately choosing the appropriate delivery guarantee per use case

For Beginners: What to Actually Do

Learn the three delivery semantics by their actual trade-off, not just their names — at-most-once risks loss, at-least-once risks duplication, exactly-once is the hard-won ideal.
Practice designing simple idempotent event handlers (using a unique event ID to detect and ignore duplicates, for example) — this is a directly transferable, foundational skill for working with at-least-once systems safely.
For any streaming use case you encounter, ask explicitly which delivery guarantee it’s actually using, and whether that matches how much loss or duplication the use case can tolerate.
Don’t assume exactly-once is always the right goal — it often comes with real performance and complexity costs that aren’t justified for use cases that could tolerate a simpler guarantee.

For Practitioners and Leaders: The Deeper Layer

Make delivery semantics a deliberate, use-case-specific decision, not a platform-wide default applied uniformly regardless of what different streams actually need.
Invest in idempotent event handling as foundational good practice for any at-least-once system — it’s usually cheaper and more robust than chasing exactly-once semantics for use cases that don’t strictly require them.
Where genuine exactly-once guarantees are needed (financial transactions, critical counters), evaluate your platform’s actual native support carefully rather than assuming you’ll need to build it entirely from scratch — this has become more achievable than it used to be.
Audit existing streaming systems for their actual delivery semantics, especially older ones built before this distinction was well understood — undocumented at-most-once behavior in a use case that actually needed stronger guarantees is a common, quietly serious gap.

Quick Recap

Delivery semantics describe a streaming system’s guarantee about event processing: at-most-once (might lose, never duplicates), at-least-once (never loses, might duplicate), exactly-once (the hardest, most valuable guarantee).
Early systems often defaulted to at-most-once for simplicity; idempotent event handling made at-least-once genuinely safe to build on for most use cases.
Modern platforms increasingly offer practical, built-in exactly-once support for well-defined scenarios, narrowing the historical gap between ideal and achievable.
The right delivery guarantee should be a deliberate, per-use-case decision based on actual sensitivity to loss or duplication, not a uniform default.

Where This Fits in the Series

Article 5 covered keeping events in order. This article covered what happens when one gets missed. Article 7 looks at what actually happens to an event while it’s in flight, before it reaches its destination.