Part 13 of 16 · Day 2 · replay, snapshot

A wrong view over a correct history

Problem and experience

The view is wrong and we need a new one

The summary calculates incorrectly. Or tomorrow someone asks something today's view cannot answer.

Bug in the code

  1. Projection v1interest rate counted as income
  2. Summaryincome changes: 3

New question

  1. “How many times did the interest rate change?”
  2. We have no view for that

From practiceWhen did you have to fix a report retrospectively and worry about everything that might happen?

TakeawayWhen the bug is in the view, we do not have to touch the history.

More on this topic

What it means

A projection is a read model derived from events. It is stored separately and keeps the position of the last processed event.

Why we use it

A bug in a view does not cause data loss. The view can be deleted and rebuilt with new code.

When it makes sense

Reports, summaries, dashboards, screens that need a different shape from the source data.

Where it breaks

  • The processing position is not stored, and after a restart everything starts from zero.
  • The projection handler is not idempotent.

Imagine

The calculation summary shows three income changes, although the adviser changed the income twice and the interest rate once.

Fixing a view need not mean touching the past.

Principle, application and exercise

Replay, rebuild and snapshot

We rebuild the view from history. While doing so we must not send the e-mail again. A snapshot shortens loading but does not replace history.

Replay

  1. Events
  2. Rebuildno-side-effects mode
  3. Projection v2opraveno
  4. Nothing was sent

Snapshot

  1. Snapshot v250
  2. Events 251…300replayed 50×
  3. State v300

Trade-offReplay takes time and runs alongside production. Faulty history is fixed not by replaying but by a correcting event. A snapshot is a cache, not the source of truth.

TakeawayRebuilding a view and performing real operations must stay separate.

More on this topic

What it means

Rebuild deletes the projection and replays the events with new code. Handlers with side effects are not called during it. A snapshot stores the state at a given version, and loading replays only newer events.

Why we use it

Fixing a view is routine. It must not produce another letter or payment.

When it makes sense

For every projection whose handler can send something. Snapshots only once we actually measure long streams.

Where it breaks

  • Commented-out code instead of a flag.
  • A stale snapshot after the aggregate code changes.
  • Deleting events after a snapshot.

Imagine

After fixing projection v2 we replay the history. The client does not get the calculation-complete e-mail a second time.

Shortening loading does not mean forgetting, and fixing a view does not mean repeating the past.

Training for your team

Would you like this training for your team?

We run the training on your code and your domain problem. We agree the scope, dates and format with you.

Discuss the training