Menu

Earn Premium with Referrals

Invite your friends and earn Premium rewards through our referral program.

See how it works and start inviting friends.

At-Most-Once Delivery
HLD

At-Most-Once Delivery

Fire and (don't) forget — when losing messages is acceptable, and the systems built on that bet.

The Contract

 AT-MOST-ONCE: each message delivered ZERO or ONE times.
 never duplicated. possibly lost.

 [producer] ──send──► broker ──► consumer
      no retries on failure anywhere in this chain

 loss scenarios accepted:
 - send fails → message gone (no retry)
 - broker crashes before persist → recent messages gone
 - consumer crashes mid-process → message already acked → gone

How Systems Achieve It

 it's the CHEAPEST guarantee — you get it by NOT doing work:

 producer side:
   fire-and-forget UDP/metrics clients
   no persistence wait, no retry logic

 broker/consumer side:
   acknowledge-on-delivery (before processing)
   no redelivery mechanism needed

 every simplification trades durability for speed/simplicity.

When Losing Messages Is Fine

DataLoss toleranceWhy
Metrics samples✓ highNext sample arrives in seconds; aggregates survive
Presence heartbeats✓ totalStale heartbeat = same info as lost one
Game position updates✓ highSuperseded by the next update anyway
Sensor readings (dense)✓ moderateInterpolation covers gaps
Logs (debug level)✓ oftenSampling is a feature
 common thread: TEMPORAL REDUNDANCY.
 if the next message largely replaces the last,
 losing some is statistically harmless.

 metrics at 10s intervals with 1% loss:
 averages/percentiles unaffected. nobody notices.

When It’s Catastrophic

 ✗ payments, orders, transfers     → money/state corruption
 ✗ user-generated content          → data loss complaints
 ✗ audit/compliance events         → legal exposure
 ✗ anything triggering side effects once-only

 rule: if a duplicate would be BAD but a loss would be WORSE,
 at-most-once is wrong. if duplicates are IMPOSSIBLE to tolerate
 but losses are fine... reconsider the design entirely.

The Hybrid Reality

 real systems mix guarantees per flow:

 telemetry:      at-most-once (cheap, dense)
 order events:   at-least-once + idempotency  
 payment auth:   synchronous request/response (not queued at all!)

 choosing per-flow is engineering;
 blanket-guaranteeing everything is cost without benefit.

Interview Framing

Delivery-guarantee questions test spectrum knowledge: define at-most-once precisely (“zero or one; losses accepted”), list its legitimate homes via temporal-redundancy reasoning (metrics/heartsbeats), and place it against siblings (at-least/exactly-once). The senior tell: proposing it PROACTIVELY for telemetry because at-least-once there is wasted machinery.

My Private Notes

Notes are auto-saved locally to this device.