Backfills & Reprocessing
Fixing history without breaking the present. Backfill ranges, late-arriving data, deduplication, merges, replay and the validation that has to happen before you publish.
Recomputing history after the logic or the inputs changed — and why the hard part is publishing the result, not computing it.
Duplicated periods, overwritten current data, a saturated warehouse and a source knocked over by its own history — the four ways a correction becomes an incident.
Five questions to answer before the first partition runs: which range, is the re-run safe, where does the compute go, how do we validate, and how do we publish.
Reconcile the range against the source, explain every old-versus-new difference, and prove a period the bug never touched is unchanged — the check people skip.
The same button means two different things: finishing work that never completed, and redoing work that completed and is now wrong.
An event that happened on Tuesday and arrived on Thursday, after Tuesday was already computed, published and read.
Which key you deduplicate on decides which duplicates you can see — and a producer retry with a fresh id is invisible to every id-based scheme.
Replacing rows by key instead of appending them — the write that makes re-running safe, and the assumptions it quietly depends on.
Rebuild everything every time, or process only what changed. The first is expensive and has no state to get wrong, and it is the right answer more often than people admit.
Re-reading a retained event log versus recomputing from the raw layer — two recovery paths with different windows, different guarantees, and retention as the hard boundary on both.