A parser bug corrupted last week's derived parking metrics. After fixing the code, what Kafka operational benefit lets the team rebuild cleanly?
Select an answer to reveal the explanation.
Short Explanation
Fix the recipe, then re-cook last week's ingredients from the pantry. Kafka's log lets you rewind the offset and run the fixed parser over the same events.
Full Explanation
After a parser bug corrupted last week’s derived parking metrics, Kafka’s operational benefit is replay from an earlier offset to re-read last week’s topic after the parser fix, rebuilding clean derived outputs without recreating physical sensors. Irreversible loss of all topic history as soon as any bug appears would make recovery impossible within retention. Mandatory recreation of every source sensor to regenerate events is unnecessary when the log still holds the raw taps. Blocking replay so defective outputs can never be corrected abandons a core log advantage. Exam caveat: replay must be coordinated with downstream idempotence or sink truncation so duplicates from reprocessing do not corrupt fixed metrics again. Operational check: after deploying the parser fix, reset the consumer to the pre-bug offset within retention, reprocess, and checksum the rebuilt parking metrics against a known-good sample day. In production terms for offset replay after parser fixes, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for offset replay after parser fixes after material dependency upgrades so regressions are caught before the next public release.