Exactly-Once Processing, Twice-Sent Notification
Read what each party saw, commit to a cause, and only then find out which of them was right. The root cause, why the obvious reading was wrong, and the fixes are all held back until you have answered.
The symptom
What was reported, before anyone knew what was happening.
What each party saw, and what each concluded
The evidence, in the form it actually arrived in — several parties, several partial views, several confident conclusions.
| Who | What they could actually see | What they concluded | Verdict |
|---|---|---|---|
| Stream processor | A transaction spanning consumption, state update and output production, committed atomically with the offset. | Every input event was processed exactly once. The guarantee held. | ✓ right |
| Notification sender (inside the processing function) | An HTTP POST to the push provider, executed during processing. | One call per invocation. | ✓ right |
| Push provider | Two POSTs with identical payloads 900ms apart. | Two notifications to deliver. | ✕ wrong |
| Engineer who enabled exactly-once | The audit confirming one output record per input. | The duplicates must come from the provider or the client SDK. | ✕ wrong |
2 of 4 parties reasoned correctly from what they could see and still reached the wrong conclusion. Nobody in this table is careless. Each one acted on complete-looking local information, and the information was local. That gap — between what a node can observe and what is true — is the whole domain, and one of these readings will usually be yours.
Commit before you read on
The exactly-once configuration is correct and the audit that proves it is sound. Commit before reading on: define precisely what "exactly-once" covers in a stream processor, and name what falls outside it.
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.