Fault Tolerance and Exactly-Once — Not Losing or Double-Counting
A stream-processing job runs forever, which means it will experience failures — nodes crash, networks partition, processes restart. The question isn't whether failure happens but what happens to your results when it does: do you lose events, double-count them, or get exactly the right answer anyway? Fault tolerance, and the famous "exactly-once" guarantee, are what separate a toy stream processor from one you can trust with money. This post is about surviving failure correctly.
A forever-running job will fail, so the delivery guarantee matters: at-most-once (may lose), at-least-once (may duplicate), or exactly-once (correct as if neither). How checkpointing and replayable sources achieve exactly-once semantics, and choosing the guarantee by need — with idempotency as the pragmatic route.