Skip to main content

Glossary

What is exactly-once delivery?

Last updated Monday, Aug 3, 2026

Exactly-once delivery is a guarantee that every event or row in a pipeline is processed exactly one time: never duplicated by a retry, never dropped by a failure. It's the strictest of the three delivery guarantees (at-most-once, at-least-once, exactly-once) and the hardest to build correctly end to end.

How it works generically

True exactly-once delivery usually needs two things working together: at-least-once delivery, so nothing gets silently dropped, paired with idempotent processing or transactional writes, so a redelivered event doesn't create a duplicate. Most systems that claim exactly-once are really at-least-once delivery plus an idempotent consumer, since guaranteeing exactly-once at the network layer alone is close to impossible in a distributed system.

Why it matters

Financial totals, inventory counts, and usage-based billing all break if a single event gets counted twice or missed once. A dashboard that's off by even a small duplicate rate erodes trust fast, and by the time someone notices the numbers are wrong, the bad data may already be baked into a report or an invoice.

Where OptimaFlo stands today

OptimaFlo does not offer a blanket exactly-once guarantee across every layer and engine. Bronze ingestion appends rows tracked by a watermark cursor, with a best-effort client-side dedup filter for REST sources that OptimaFlo's own code documents as incomplete for at least one ingestion mode. Athena has a real server-side MERGE capability built for Gold, but it is not wired into the canonical Gold-incremental path; the path that is wired uses a local, keyed merge (DELETE+INSERT by key), not a server-side MERGE INTO. Every warehouse write method is explicit that it does not deduplicate: the caller is responsible for a clean source. Retry safety in OptimaFlo depends on which layer and engine you're looking at, not a single platform-wide promise.

Related terms

  • Idempotent pipeline: The property that gets you close to exactly-once behavior even when true exactly-once delivery isn't guaranteed.
  • Change data capture: CDC systems often promise at-least-once or exactly-once delivery of change events; see how that compares to OptimaFlo's read model.

Frequently asked questions

At-least-once guarantees nothing gets dropped, but a retry can deliver the same event twice. Exactly-once adds the guarantee that duplicates never happen either. Most real systems build exactly-once behavior by combining at-least-once delivery with idempotent processing downstream, rather than solving it at the network layer alone.

Not as a single platform-wide guarantee. Retry and duplicate handling varies by layer: Bronze uses a watermark cursor and a best-effort dedup filter, and Gold's real merge capability exists in the codebase but isn't wired into the default incremental path yet.

Yes, by writing your SQL with a stable key and a merge or overwrite pattern instead of a plain append, so a rerun does not produce duplicate rows.

Browse every term or see the AI data team roles.

Staffed, not self-serve

See AI teammates work on your own data.

Now in early beta. One flat plan, no per-query tax. Runs in your cloud, and your tables stay in your account.