You've probably seen a message broker advertise "exactly-once delivery." It's marketing. The Two Generals Problem proves that two parties communicating over an unreliable channel can never reach guaranteed agreement on a single action. Every distributed system you build inherits this limitation, whether you acknowledge it or not.

The setup: two generals must coordinate an attack. They communicate only by messenger, and messengers can be captured. General A sends "attack at dawn." Did it arrive? A needs an ack. B sends an ack — did that arrive? A needs to ack the ack. The recursion never bottoms out. No finite number of messages produces certainty.

This isn't academic. It shows up every time you charge a credit card:

• Your service calls Stripe. The network drops the response.
• Did the charge succeed? You don't know.
• Retry — and you might double-charge. Don't retry — and you might lose money.

The honest engineering answer is to pick your failure mode and design for it:

• At-most-once: send and forget. Fast, lossy. Fine for metrics, fatal for payments.
• At-least-once: retry until acked. Reliable, but duplicates are guaranteed eventually. Your consumer must be idempotent.
• "Exactly-once" semantics: at-least-once delivery plus deduplication at the consumer using a unique key. The wire still sees duplicates; the effect happens once.

Real-world example: Stripe's API requires an Idempotency-Key header. You generate a UUID per logical operation. Retry the request 50 times with the same key and Stripe processes it exactly once, returning the cached result for retries. The "exactly-once" guarantee lives in your key plus their storage, not in the network.

Rule of thumb: if a message triggers a side effect (payment, email, inventory decrement), assume it will be delivered at least twice. Budget for it: every consumer needs either an idempotency key, a dedupe table, or an operation that's naturally idempotent (like SET status = 'paid' rather than UPDATE balance = balance - 10).

A practical dedupe pattern: store processed message IDs in a table with a 7-day TTL. Before processing, INSERT ... ON CONFLICT DO NOTHING. If the insert returned 0 rows, you've seen this message — skip it. Cheap, correct, and survives consumer crashes.

The mistake juniors make is treating "exactly-once" as a configuration toggle. Seniors treat it as a property the application enforces, knowing the transport can't.