A notification service must deliver push notifications for mentions. What delivery guarantee do you offer, and how do you avoid sending duplicates?

What the interviewer is testing

Whether you can state a guarantee honestly and know that deduplication has to happen somewhere specific.

The guarantee

At-least-once, with deduplication at the send boundary.

Exactly-once delivery over an unreliable network is not achievable — the classic result — and any system claiming it is either deduplicating somewhere or is wrong. The honest statement is at-least-once plus an idempotent effect.

Note that push delivery is best-effort regardless: the platform push services may delay or drop, so even a correct pipeline cannot promise the notification arrives. The client must reconcile on next open, which is the real guarantee the product depends on.

Avoiding duplicates

A deterministic notification identifier derived from the triggering event — the message id plus the recipient id — not a generated value. Every retry produces the same identifier.

Record sent notifications keyed by that identifier, and check before sending. The record and the send must be committed atomically, or a crash between them re-sends.

Pass the identifier to the push provider where supported, so their infrastructure deduplicates too.

A retention window on the dedup record sized against the longest plausible retry, stated explicitly. A duplicate arriving after the window will be sent.

The failure that defeats it

Generating the identifier per attempt rather than per logical notification. This is the same defect that defeats idempotency keys in payment APIs, and it is invisible in testing because retries rarely occur there.

What a strong answer adds

Coalescing as a product requirement, not just a technical one. Twenty mentions in a busy channel should not produce twenty push notifications. Batching within a window, and suppressing notifications for a channel the user is actively viewing, is what makes the feature tolerable — and it is a delivery decision that belongs in the pipeline rather than being left to the client.

And the ordering point: notifications need no cross-channel ordering guarantee, which removes a substantial constraint from the design and should be stated rather than assumed.

Common weak answers

Claiming exactly-once. Deduplicating in the client, which does not prevent the push being sent.