Tensions in Practice: Direct current reads in tension with replayable history¶
Event history · deterministic updates
A counter starts at 1. Adding 2 and then multiplying by 3 leaves it at 9. A store containing only the current value answers “what is it now?” immediately, but 9 does not identify those earlier steps. Retaining the initial value and ordered operations makes the intermediate 3 and final 9 reproducible by replay. That extra capability requires a complete record and repeated computation when rebuilding.
Keep current-state access simple
Read and update the value that present work needs without maintaining a replay history.
Reconstruct earlier and derived states
Keep enough ordered context to rebuild how the current value arose.
Why these aims pull against each other
A final value can summarize many different histories. Reconstruction requires retaining the inputs and update rules that the summary discarded, plus work to apply them again.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Current only
Replace the current value as each operation occurs; the final retained value is 9.
- What it protects
- Present reads use one current value without replaying prior operations.
- What it costs
- The retained value alone cannot recover the intermediate 3 or distinguish this history from another route to 9.
- When it fits
- Only the present value is required and no audit or reconstruction promise depends on discarded events.
Illustration note: The diagram stipulates a current-only store with no separate backup or event log. Updates are correct; this is a deliberately narrower retention contract.
Retain and replay
Retain initial value 1 and the two ordered events, then derive the view by the specified fold.
- What it protects
- The view can be rebuilt, and the intermediate state is inspectable without rewriting the log.
- What it costs
- Retaining history costs storage; rebuilding requires executing the prior steps, and live projections may lag new events.
- When it fits
- Events are complete, ordered and meaningful under a deterministic update rule, with initial state and rule version available.
Illustration note: The counter and arithmetic are editorial. Replay of external effects, unrecorded inputs, or a changed rule is not guaranteed to reproduce the original system.
What this illustration does—and does not—establish
Logging: Log versus Current State distinguishes state and history. Event-Sourced Projection supplies deterministic folding, disposable views and rebuild costs.
- The example rebuilds a value, not a sent message or other irreversible external effect.
- A log does not automatically prove completeness, honest capture, or causation.
- Snapshots can shorten replay; maintaining both log and fast projection adds coordination rather than eliminating cost.
Source entries
Logging
Logging: Log versus Current State supplies the conflict examined here.
Log versus Current State
The log records what happened; the current state records what is true now — different objects with different correctness properties (auditability lives in the log, performance in the state).
Event-Sourced Projection
Defines the ordered fold that makes the retained events operationally reconstructive.
How it works
- Derive by folding. A projector applies events left-to-right into the read shape — a deterministic reduction of history into current state.
When it helps, and when it misleads
It misleads when the log grows large and replay becomes slow — a cold rebuild can take hours without periodic *snapshots* to start from.