Architecture scenarioHard~12 min

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat replay as an operational change with runbooks, metrics, and rollback. I would monitor replay lag, write rate, error rate, dead letters, database pressure, and validation differences. I would also avoid replaying events that trigger external side effects like emails unless the handler explicitly suppresses them. Replay is safest when handlers distinguish state reconstruction from live business action.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain idempotent projection updates.
Has no cutover or validation plan.
Ignores schema evolution.
No throttling or operational metrics.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid replaying side effects?
How would you validate the rebuilt projection?
What would you do with events using old schemas?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Partition KeyArchitecture scenario / Hard / ~12 minContinue Queue vs TopicComparison question / Easy / ~5 minContinue Message EnvelopeConcept question / Medium / ~7 minContinue

Opening drill

Architecture scenarioHard~12 min

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would treat replay as an operational change with runbooks, metrics, and rollback. I would monitor replay lag, write rate, error rate, dead letters, database pressure, and validation differences. I would also avoid replaying events that trigger external side effects like emails unless the handler explicitly suppresses them. Replay is safest when handlers distinguish state reconstruction from live business action.

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.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain idempotent projection updates.
Has no cutover or validation plan.
Ignores schema evolution.
No throttling or operational metrics.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid replaying side effects?
How would you validate the rebuilt projection?
What would you do with events using old schemas?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Partition KeyArchitecture scenario / Hard / ~12 minContinue Queue vs TopicComparison question / Easy / ~5 minContinue Message EnvelopeConcept question / Medium / ~7 minContinue

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 practice

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 practice