Exactly-once as a practical trade-off

True exactly-once end-to-end across brokers, databases, and third parties is impractical without cooperation at every layer. Production systems aim for effective exactly-once: at-least-once delivery plus idempotent consumers, transactional outbox, or deduplication within a defined scope.

Kafka transactional produce and consume within one cluster is a bounded guarantee — it does not magically deduplicate email sends or payment API calls. State the scope: within partition ordering, within database transaction, within idempotency key window.

On interviews: push back on "we need exactly-once" by asking which invariant must hold, then propose at-least-once plus idempotency or outbox for that invariant.

Common pitfalls: marketing exactly-once without defining boundaries; ignoring duplicate side effects outside the broker; transactional overhead accepted without measuring need; conflating offset commit with business completion.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Name the invariant that must not duplicate.
• Choose delivery semantics for that scope only.
• Add idempotency or outbox where needed.
• Document what is not covered by the guarantee.