How would you replay events to rebuild a projection or backfill a new read model?

Design safe event replay and backfill

Explains how to reprocess event streams safely for new projections, bug fixes, and data repair.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would create a separate replay or backfill process that reads historical events and writes to the new projection or repaired table. The projection updates need to be idempotent because replay may restart. I would keep replay isolated from live consumers where possible, and I would define whether the rebuilt data includes all history or a bounded time range.

Full answer below

Practice focus

Replay, backfill, idempotent projections, versioned handlers, cutover, throttling, and operational safety.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Replay is one of the main benefits of event streams, but it can damage production systems if treated like a normal live consumer.
I would create a separate replay or backfill process that reads historical events and writes to the new projection or repaired table. The projection updates need to be idempotent because replay may restart. I would keep replay isolated from live consumers where possible, and I would define whether the rebuilt data includes all history or a bounded time range.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would handle schema versions and old business rules explicitly. Historical events may not contain fields added later, and old event meaning may differ from today's code. For a new read model, I might rebuild into a shadow table, validate counts and samples, then cut over reads. Throttling matters because replay can overwhelm the database, broker, or downstream services if it runs at full speed.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Replaying historical events through handlers that send real emails or payments.
Ignoring old schema versions.
Writing directly into the live projection with no validation.
Running replay at unlimited speed against production dependencies.

How would you replay events to rebuild a projection or backfill a new read model?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement