Why messages get lost, duplicated, or reordered, and how to fix it
At-most-once, at-least-once, and "exactly-once" delivery. Why messages go missing or arrive twice, and how idempotency, dedup, sequence numbers, and per-key ordering handle it. The duplicate and dedup behavior was checked in Node, and the HTTP idempotency facts against RFC 9110.
Questions
- Not answered. In an at-least-once system, why can the receiver get the same message twice even though the network never corrupts data?
- Not answered. Why do engineers call exactly-once delivery practically impossible, 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 they were sent. What most often breaks that order?
- Not answered. A queue enforces strict total ordering, so each message waits until all earlier ones are handled. What's the built-in cost?
- Not answered. Which classic thought experiment shows that two parties can never be certain they agree over a lossy channel? It's the theoretical reason exactly-once delivery is impossible.
- Not answered. A high-frequency telemetry feed can live with an occasional dropped reading, but duplicates would corrupt its counters. Which delivery guarantee fits best?
- Not answered. You dedup by remembering the ids you've already processed. What's the catch in practice?
- Not answered. Which techniques help a consumer keep or restore order in a real-time stream?
- Not answered. When a system advertises "exactly-once semantics" (for example, Kafka EOS), what does that actually mean?
- Not answered. Per RFC 9110, how many HTTP methods are idempotent?