Comparison
Event sourcingvsReplay
Event sourcing
you stop storing the current balance and instead store every deposit and withdrawal, deriving the balance by replaying them.
Persisting state as an ordered log of immutable events, with current state as a derived projection. You get a complete audit trail and the ability to rebuild any view by replaying history. What you give up is ad-hoc querying, cheap schema change, and the ability to ever delete anything easily — events are forever, including the ones with a bug in them.
Full entry →Replay
you fixed the bug and reset the consumer back to last Tuesday so it processes the last week of events again correctly.
Re-reading retained messages from an earlier position to rebuild state or recover from a processing bug. It is one of the main reasons to choose a log over a queue. It also re-triggers every side effect the consumer performs, so a consumer that sends emails needs a replay mode before you ever need to replay it.
Full entry →