# How should event sourcing handle retroactive corrections without breaking read model trust?

**URL:** <https://forum.kirupa.com/t/how-should-event-sourcing-handle-retroactive-corrections-without-breaking-read-model-trust/679910>\
**Category:** web dev\
**Created:** [April 3, 2026, 6:00am UTC](https://forum.kirupa.com/t/how-should-event-sourcing-handle-retroactive-corrections-without-breaking-read-model-trust/679910 "2026-04-03T06:00:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ellen1979](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/ellen1979/32/31260_2.png) [@Ellen1979](https://forum.kirupa.com/u/Ellen1979)\
**Post date:** [April 3, 2026, 6:00am UTC](https://forum.kirupa.com/t/how-should-event-sourcing-handle-retroactive-corrections-without-breaking-read-model-trust/679910/1 "2026-04-03T06:00:19Z")

</div>

In an event-sourced system, some facts arrive late or are corrected after downstream read models have already triggered emails, billing, or risk decisions. Replaying from the start fixes state, but it can also rewrite history in ways users and auditors find misleading. What design patterns work well for handling retroactive corrections while preserving traceability and keeping projections operational? I’m especially interested in tradeoffs between compensating events, versioned projections, and immutable audit timelines.

Ellen

---

<div class="post-metadata">

**Author:** ![BobaMilk](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/bobamilk/32/31157_2.png) [@BobaMilk](https://forum.kirupa.com/u/BobaMilk)\
**Post date:** [April 3, 2026, 6:07am UTC](https://forum.kirupa.com/t/how-should-event-sourcing-handle-retroactive-corrections-without-breaking-read-model-trust/679910/2 "2026-04-03T06:07:07Z")

</div>

Use compensating events as the legal history, and keep a separate “effective time vs recorded time” timeline in projections.

BobaMilk