Why Exactly-Once Delivery Is Non-Negotiable for Event-Driven Systems

Most messaging systems offer one of two guarantees: at-most-once (messages may be lost but never duplicated) or at-least-once (messages may be duplicated but never lost). For general-purpose applications, at-least-once is usually good enough — duplicates are annoying but rarely dangerous.

In event-driven systems, duplicates can be catastrophic. A duplicated payment event might trigger a billing service to charge a customer twice. A repeated deployment webhook might cause a CI/CD pipeline to deploy the same artifact twice, creating race conditions. A triplicated incident alert during an outage floods the very channel that responders need to coordinate through.

ATT's delivery engine achieves exactly-once semantics through a combination of idempotency keys, persistent deduplication windows, and a two-phase commit protocol between the event store and the delivery transport. Every event is assigned a globally unique, content-addressed identifier at ingestion. Before delivering to any endpoint, the engine checks the identifier against a per-consumer deduplication index that spans a configurable time window — typically 24 hours.

The cost of this guarantee is a small amount of additional storage and a single index lookup per delivery, which adds roughly 15 microseconds to the critical path. In our experience, every client who has evaluated this trade-off has concluded that 15 microseconds is a trivial price for the confidence that every event arrives exactly once.