Skip to content

Append-Only Event Store

Storage tool / infrastructure component — instantiates Event-Log-Centered Modeling

An immutable, ordered store that only ever accepts new events and never edits old ones, serving as the single source of truth from which all state is derived.

The whole archetype rests on one durable promise: that the record of what happened is never overwritten. Append-Only Event Store is the component that makes that promise physical. It accepts events, assigns each one a permanent position in an ordered sequence, and thereafter refuses to mutate or delete them — the only write operation it offers is append. Everything else in the system — current balances, entity states, dashboards — is a derived view that can be thrown away and rebuilt, because the store, not any of those views, holds the authoritative history. Its defining move is to make history write-once and position-stable: two readers who ask "what were events 1 through N" always get the same answer, in the same order, forever. That single guarantee is what lets everything downstream be reproducible.

Example

A payments company runs its core ledger as an append-only store. When a customer sends money, the system does not update a "balance" field; it appends a FundsReserved, then a FundsCaptured, then a TransferSettled event, each stamped with a monotonic sequence number as it lands. The customer's current balance is not stored anywhere authoritative — it is folded from those events on demand. When a dispute arrives eight months later, there is no "what did the balance used to be" guesswork: the store still holds every event in its original order, so the exact state at any past instant can be reconstructed by replaying up to that point.

The payoff shows up the day a projection bug ships that mis-computes fees. In a mutate-in-place system the wrong numbers would already have been written over the right ones. Here the derived balances are simply discarded and recomputed from the untouched log once the projection is fixed — the source of truth was never corrupted, only a downstream reading of it. Concurrency is handled at append time: two processes trying to record conflicting events against the same account attach an expected-version, and the store rejects the stale one rather than silently interleaving them.

How it works

What distinguishes the store from an ordinary database is the narrowness of what it allows:

  • Append is the only mutation. There is no UPDATE and no DELETE on committed events; correcting the record means appending a new event, never editing an old one.
  • Every event gets a stable position. On commit the store assigns a monotonic sequence marker (a global offset or per-stream version) that fixes the event's place in the order for all time.
  • Order is settled at write time. Concurrent appends are resolved with an optimistic expected-version check, so the canonical sequence is decided once, at ingestion, rather than argued over later.
  • It advertises itself as the source of truth. Downstream views reference the store as authoritative and treat their own contents as disposable caches.

Tuning parameters

  • Ordering scope — a single global total order versus per-stream (per-aggregate) ordering. Global order is simplest to reason about but throughput-limited; per-stream order scales but only guarantees sequence within a stream.
  • Concurrency control — how strict the expected-version check is on append. Strict optimistic locking prevents lost updates but forces retries under contention; looser control trades some safety for write throughput.
  • Durability / replication — how many replicas must acknowledge before an append is "committed." More replicas mean stronger survival guarantees and higher write latency.
  • Stream granularity — how finely events are partitioned into streams. Fine streams parallelize well but make cross-stream ordering weaker; coarse streams keep order tight but bottleneck.
  • Retention posture — whether the raw log is kept indefinitely or handed to a compaction/retention process; the store enforces immutability, but how long is a policy dial set elsewhere.

When it helps, and when it misleads

Its strength is that it turns "what happened" into an asset that cannot be quietly corrupted: audits become replays, bugs in derived state become rebuildable rather than catastrophic, and new questions can be asked of old history because the history is still there. This is the event-sourcing[1] foundation the rest of the archetype builds on.

It misleads when teams treat the store as if it were also the read model. Querying current state by scanning the whole log is ruinously slow — the store is optimized for append and ordered read, not for "give me every customer over their limit right now"; that is a projection's job, and skipping projections is the classic misuse. An append-only log also grows without bound and can silently accumulate personal data that was never meant to live forever, so immutability without a retention and access discipline becomes a liability, not a virtue. The guarding discipline is to keep the store authoritative but thin — it stores and orders, and everything interpretive lives in derived views that reference it.

How it implements the components

Append-Only Event Store realizes the storage-and-ordering substrate of the archetype — the components that make history durable and canonically ordered:

  • event_log — it is the log: the append-only, ordered container of all events.
  • source_of_truth_reference — it is the designated authority every derived view points back to.
  • timestamp_or_sequence_marker — it assigns each event its permanent monotonic position on commit.
  • event_ordering_and_concurrency_rule — it settles order at write time via expected-version optimistic concurrency.

It does not shape or interpret events: the event contract and captured fields come from Event Capture Template, state is reconstructed by Deterministic Replay Protocol, and the two-clock history is kept by Bitemporal Event Register. The store only stores and orders.

Notes

The store's authority is only as strong as the discipline that keeps derived state out of it. The moment someone begins writing computed balances or statuses back into the log as if they were events, the "source of truth" quietly becomes a mix of fact and interpretation, and the reproducibility guarantee erodes. Events should record what happened; conclusions drawn from them belong in projections that can be rebuilt.

References

[1] Event sourcing — the pattern of persisting all changes to application state as an ordered sequence of immutable events, and deriving current state by replaying them, rather than storing only the latest state. The append-only store is its enabling substrate. ↩