Reprocessing Window
How far back a pipeline can be replayed, set by the shortest retention anywhere along the path rather than by intent.
Reprocessing is the answer to a logic bug, a schema correction or a new derived field over history. Its feasible extent is decided long before it is needed, by retention settings in the input log, in intermediate topics, and in whatever the source system keeps.
The binding constraint is the shortest one on the path, and it is usually an intermediate topic left at a default of seven days. The input may be retained for a year; if a middle stage discarded its record of what it emitted, the replay cannot pass through it without recomputing that stage too — which may not be possible if it was stateful and its state has expired.
The other half of the design is what happens to output while a replay runs. Three arrangements: write to a parallel output and swap consumers when it has caught up, which is cleanest and costs a duplicate sink; write to the same output with idempotent keys so re-emission overwrites, which requires an idempotent sink; or stop live processing during the replay, which is rarely acceptable.
Deciding this at design time is what turns reprocessing from a project into an operation. Deciding it during an incident is how a data correction takes a fortnight.