Exactly-Once Semantics in Distributed Systems
Idempotent operations, deduplication, two-phase commit, sagas, and consistency guarantees in distributed systems
Distributed systems over unreliable networks must define delivery semantics for messages/requests. At-Most-Once: message delivered 0 or 1 times.
Implementation: no retries. Problem: lost messages acceptable?
Rarely. At-Least-Once: message delivered 1+ times.
Implementation: retry until ACK received. Problem: duplicates possible (network ACK lost, retry sent).
Exactly-Once: message delivered exactly 1 time. Implementation: hard (impossible to guarantee); use idempotent operations + deduplication instead.
Real-world: At-least-once common in practice (Kafka, RabbitMQ); exactly-once simulated via idempotency. Exactly-once semantics: define behavior such that duplicates don't cause problems (idempotent).
Example: payment (exactly-once required; paying twice = disaster) vs analytics (at-least-once acceptable; double-count is minor). Cost: exactly-once is expensive (deduplication, state management); use only when necessary.
Key Takeaways
Visual Diagram
Client -> Server: At-most-once (no retry), At-least-once (retry until ACK), Exactly-once (idempotent + dedup)