exactly once

Pipelines fail and retry; the real question is whether a retry corrupts your data. The signal is idempotent writes (not 'exactly-once delivery') plus watermarks for late data. Here is how to make re-runs safe without double-counting.

At-least-once duplicates and at-most-once loses data; everyone wants exactly-once and few can explain how Kafka delivers it. The signal is idempotent producers plus transactional read-process-write plus the read-committed isolation that ties them together.

In payments, a duplicate charge or a lost credit is not a bug, it is a financial incident. The design hinges on idempotency keys, double-entry bookkeeping, and an append-only ledger that can be audited and reconciled. Here is how money systems stay correct.

Background jobs fail, retry, and get redelivered. If a job sends an email or charges a card, running it twice is a real problem. The design is at-least-once delivery plus idempotent handlers, visibility timeouts, and dead-letter queues. Here is how to make jobs safe.