Message Delivery: Guarantees, Ordering & Idempotency
At-most-once vs at-least-once vs "exactly-once," why duplicates and gaps happen, and how idempotency, dedup, sequence numbers, and per-key ordering tame them. The duplicate/dedup behavior and HTTP idempotency facts are verified in Node and against RFC 9110.
Questions
- Not answered. In an at-least-once system, why can a receiver get the same message twice even when the network never corrupts data?
- Not answered. Why do engineers say "exactly-once delivery" is essentially unattainable — and what do real systems offer instead?
- Not answered. Which statements about idempotency in message delivery are correct?
- Not answered. Messages on a single WebSocket connection arrive in the order sent. What most commonly breaks that?
- Not answered. A queue enforces strict total ordering — each message is handled only after all earlier ones. What's the inherent cost?
- Not answered. Which classic thought experiment proves two parties can never be certain they agree over a lossy channel — the theoretical root of why exactly-once delivery is unattainable?
- Not answered. A high-frequency telemetry feed tolerates an occasional dropped reading, but duplicates would corrupt aggregate counters. Best delivery guarantee?
- Not answered. You dedup by remembering the ids you've already processed. What's the practical catch?
- Not answered. Which techniques help a consumer preserve or restore order in a real-time stream?
- Not answered. When a system advertises "exactly-once semantics" (e.g. Kafka EOS), what does it really mean?
- Not answered. Per RFC 9110, how many HTTP methods are idempotent (the safe methods plus PUT and DELETE)?