Your streaming job has exactly-once semantics enabled. Customers report receiving the same email twice. Explain.

What the interviewer is testing

Whether you know where the exactly-once guarantee actually ends — the most commonly misunderstood boundary in streaming.

The explanation

Exactly-once semantics guarantees effect within the transactional boundary of the framework. The processed output, the updated state and the consumed offset commit atomically, so on failure all three roll back together.

Sending an email is outside that boundary. The email provider knows nothing about the transaction. So the sequence is: process the record, call the email API (email sent), then attempt to commit — and if the commit fails or the job crashes before it, the offset is not advanced. On restart the record is reprocessed and the email is sent again.

The framework's guarantee is intact. The email was always outside it.

This applies to every external side effect: HTTP calls, payments, notifications, writes to a database outside the transaction, file writes.

The fix

Idempotency at the boundary, which is the durable answer regardless of framework guarantees:

• Pass an idempotency key derived deterministically from the record — the event id, not a generated value — so the provider deduplicates. Most transactional email and payment providers support this.
• Or record "email sent for event X" in the same transactional store as the processing state, and check it before sending. This narrows the window but does not eliminate it, since the crash can still occur between sending and recording.
• Or use the outbox pattern: the job writes an email request transactionally, and a separate dispatcher with its own idempotency handling sends it.

What a strong answer adds

The general design rule: exactly-once inside the framework plus idempotent effects outside it is the combination that holds. Enabling exactly-once costs throughput and latency, so it should be a deliberate choice for the state that needs it — and it never removes the need for idempotent boundaries.

Common weak answers

Assuming the configuration is broken. Proposing to disable exactly-once, which changes nothing about the email.