Stable Event Identity

At-least-once delivery is the only guarantee achievable across a network you do not control, because the sender cannot distinguish "the consumer did not receive it" from "the consumer processed it and the acknowledgement was lost."

That guarantee is only usable if the consumer can recognise a duplicate. A stable event identifier — generated once when the event occurs, never regenerated, identical across every attempt — is what makes that possible.

Why it matters

Without it, at-least-once is indistinguishable from at-least-once-with-random-corruption. The consumer has no way to deduplicate however carefully they implement, and every retry produces a real duplicate side effect: a second invoice, a second shipment, a second notification.

It is also easy to break invisibly. An implementation that constructs the payload fresh on each attempt, or that derives an ID from a delivery timestamp, produces a different ID each time and nobody notices until a customer reports duplicate charges.

Implementation patterns

• Generate the ID when the event occurs, store it with the event, and use it for every attempt.
• Persist the event durably before attempting delivery, so it survives broker failure and can be redelivered days later.
• Send delivery-attempt metadata separately — attempt number, first-sent timestamp — so a consumer can distinguish a retry from a new event without the ID changing.
• Scope ordering to the subscription rather than globally. Global ordering across all customers is a single serialisation point that cannot scale; per-subscription ordering is what actually matters — a cancellation must not precede its creation — and it partitions cleanly.
• Provide a replay API, because every consumer eventually needs to reprocess a window and without one they will ask you to resend manually.
• Document the guarantee explicitly. A consumer who believes delivery is exactly-once will not write deduplication, and will discover the truth during your first retry storm.
• Require the consumer to record the ID in the same transaction as the side effect. Processing then recording is not idempotent; it is a smaller window.

Industry example

Subscription-billing platforms such as Chargebee and event-routing platforms such as Segment both live on this property. In billing, a duplicated event is a duplicated charge; in event routing, the platform fans one event out to many destinations, each of which retries independently, so a stable ID is what allows every destination to deduplicate on its own.

The same requirement governs payment-status callbacks, shipping updates and any provider-to-customer event stream.

Failure scenarios

• ID regenerated per attempt, making deduplication impossible.
• ID derived from delivery time or payload hash that includes variable fields.
• Global ordering promised, creating a serialisation bottleneck that eventually forces the guarantee to be quietly dropped.
• No replay API, so recovery becomes a manual support process.
• Consumers preserving order at the transport and then processing concurrently, discarding the ordering they were given — the most commonly missed half of the design.
• No reconciliation, so an event that was never delivered at all is discovered by a customer.

Trade-offs

Durable event storage with replay is real infrastructure: storage cost, retention policy, and a replay path that must not itself become a denial-of-service vector against consumers.

The alternative — fire-and-forget delivery — is cheaper and shifts the entire correctness burden to consumers who have no way to detect what they missed. For anything with financial consequence that is not a trade-off, it is an abdication, which is why durable storage plus stable identity is the baseline in this category.

Interview question

"A customer says they were billed twice from one of your events. Walk me through every point where a duplicate could have been created, and tell me which one your design actually prevents."