At-Least-Once Delivery

The Contract

 AT-LEAST-ONCE: every message delivered ONE or MORE times.
 never lost. possibly duplicated.

 achieved by retrying everything ambiguous:

 send → timeout? RETRY (maybe first one landed!)
 process → ack lost in network? broker REDELIVERS
 consumer crashes pre-ack? message comes back

 the system cannot distinguish "failed" from "succeeded
 but confirmation lost" — so it assumes failure and retries.
 duplication is the PRICE of guaranteed delivery.

Where Duplicates Come From

 trace any duplicate to an ambiguity window:

 1. producer retries after send-timeout
    (original actually reached broker → two copies)
 2. broker redelivers after visibility/lock expiry
    (consumer still processing, just slow)
 3. consumer processes, crashes before ack
    (restart → same message again)
 4. network partition heals with replayed deliveries

 none are bugs — all are THE DESIGN working as specified.
 duplicates are structural; handle them structurally.

Idempotency: The Mandatory Companion

 at-least-once WITHOUT idempotent consumers = corrupted state:

 "charge card $20" processed twice = real money twice.
 
 making consumption safe:
 - DEDUPE TABLE:   seen_ids checked/set atomically per message
 - NATURAL KEYS:   upsert semantics (same event → same row)
 - VERSION/CAS:    apply only if version advances  
 - IDEMPOTENCY KEYS: client-supplied, server-deduplicated
 
 if event_id dedupe table lives in the SAME transaction
 as the effect → exactly-once EFFECTS from at-least-once
 DELIVERY. this pairing is the production standard.

The Guarantee Spectrum Positioned

Guarantee	Loss	Dupes	Consumer duty
At-most-once	possible	never	nothing
At-least-once	never	possible	idempotency
Exactly-once	never	never	framework trust

 exactly-once exists (kafka transactions etc.) but carries
 throughput/complexity costs and STILL needs end-to-end care.
 most systems: at-least-once + own dedup = pragmatic exactly-once.

Operational Discipline

 □ dedupe windows sized to max redelivery horizon
   (broker retention vs dedupe table TTL must align!)
 □ monitor DUPLICATE RATE per topic (spikes = infra trouble signal)
 □ redelivery storms need backoff (poison-message lessons)
 □ ordering + at-least-once interact: retries can reorder;
   sequence numbers detect it (ordering lesson)

Interview Framing

“Your queue guarantees at-least-once — what does that obligate?” scored answer: the ambiguity-window explanation (why dupes are structural), idempotent-consumer patterns with the same-transaction dedupe trick highlighted, and the framing sentence: “at-least-once delivery plus idempotent processing equals effectively-exactly-once effects.” That equation is what interviews listen for.