Write correct history
Set aggregate boundaries, stable stream identity, expected versions, and schema contracts before facts become permanent.
Event store field guide
Production event-sourcing patterns, implemented in a real event store.
Ten focused guides for designing immutable streams, safe writes, rebuildable views, historical queries, and recoverable consumers with AllSource Core.
Category first
Core is purpose-built event store database. Query Service derives tenant-facing views. Prime builds agent memory from same durable history.
Build disposable views
Fold immutable events into projections that can rebuild, migrate side by side, and recover from durable checkpoints.
Operate through time
Replay safely, reconstruct point-in-time state, preserve tenant boundaries, and explain every derived answer from source events.
Ten patterns
Follow one technical question at a time
Each page gives direct answer, design choices, AllSource implementation, failure modes, production checklist, and related next steps. No generated city-and-keyword permutations.
- 01Aggregate streamsAn aggregate stream is the ordered history for one consistency boundary, such as an order, account, or workflow. Give every aggregate a stable entity ID, append only facts owned by that boundary, and derive current state by folding its events in version order.Read pattern
- 02Optimistic concurrencyOptimistic concurrency protects a stream by accepting a write only when its expected version matches the current version. A mismatch means another command changed the aggregate first, so the caller must reload events, re-evaluate the command, and either append a new valid event or report a domain conflict.Read pattern
- 03Projections and read modelsA projection folds ordered events into a query-specific read model. It is derived state, not a second source of truth: operators must be able to discard it, replay source events, and build a replacement without rewriting event history or stopping existing readers.Read pattern
- 04Snapshots and checkpointsA snapshot stores derived aggregate state at a known point in its history; a checkpoint stores how far a consumer processed the event log. Both speed recovery, but neither replaces source events. Snapshot validity depends on reducer compatibility, while checkpoint validity depends on consumer identity and delivery semantics.Read pattern
- 05Event replayEvent replay reads immutable events again in their original stream order and applies them to a new or reset consumer. Use replay to rebuild projections, reproduce historical state, test new reducers, or backfill derived outputs—never to re-trigger uncontrolled external side effects.Read pattern
- 06Idempotent consumersAn idempotent event consumer produces the same durable result when it receives an event more than once. Use stable event IDs, entity versions, unique effect keys, and acknowledge only after processing succeeds; at-least-once delivery then becomes recoverable instead of corrupting state.Read pattern
- 07Event schema evolutionEvolve event schemas by preserving stored facts, registering versioned contracts, making compatible additive changes, and translating old payloads at read time when semantics change. Never rewrite production history merely to match newest application model.Read pattern
- 08Temporal queriesA temporal query reconstructs entity or system state at a specified stream version or timestamp by selecting only facts accepted by that coordinate and folding them in order. It answers what was recorded then, while current-state query answers what is recorded now.Read pattern
- 09Multi-tenant streamsA multi-tenant event store must enforce tenant scope before every read, write, replay, subscription, snapshot, and projection operation. Tenant identity is an authorization boundary carried independently from aggregate identity; matching entity IDs in two tenants must never share history or derived state.Read pattern
- 10Durable subscriptionsA durable subscription gives a named consumer a server-tracked position in the event log. After reconnect, event store replays committed events after last acknowledged position, then switches consumer to live delivery. Processing remains at least once, so handlers must be idempotent.Read pattern
Put patterns to work
One durable record. Many rebuildable uses.
- CRC32-checked write-ahead log
- Parquet persistence and compact reads
- Point-in-time reconstruction and snapshots
- Durable consumers and schema governance