A Rust event store is useful when history is part of your product contract, not an implementation detail. Account balances, order decisions, agent memories, and audit evidence depend on how state changed. Keeping only the latest row makes that sequence somebody else's problem.
AllSource Core stores the sequence directly. This guide maps public claims to source paths, then shows what to measure before choosing the model.
Storage boundary
An accepted event enters an append-only stream. Core writes it to a CRC32-checked write-ahead log, updates concurrent indexes, and later compacts durable history into Parquet. Recovery replays persisted history to rebuild disposable in-memory state.
- WAL controls crash recovery and configurable fsync behaviour.
- Parquet gives compact columnar persistence for scans and analytics.
- Concurrent indexes answer hot reads without becoming another source of truth.
Start with Core source, then inspect architecture explanation. Public API sits on top of that storage boundary; it does not replace it with PostgreSQL.
Event shape
Useful events name a past-tense fact and carry enough identity for deterministic reads:
{
"event_type": "order.payment_failed",
"entity_id": "order_7f3a",
"stream_id": "orders",
"payload": { "attempt": 3, "provider_code": "insufficient_funds" }
}Do not use an event as a disguised mutable-row dump. Prefer facts such as order.placed, payment.authorised, and payment.failed. Projection code can fold those facts into current order state while preserving why that state exists.
Reads are separate jobs
AllSource Query Service separates four read paths over Core history:
- HTTP queries for request-response application reads.
- Realtime channels for live event and projection updates.
- Analytics endpoints for aggregates and operational questions.
- Rebuildable projections for current-state views.
See Query Service boundary and projection lifecycle. This is practical CQRS: one durable history, several read shapes, no second primary database.
Replay contract
Replay is not “run everything again” without controls. Production replay needs fixed event scope, time or version boundary, target projection, affected read models, progress evidence, and explicit switch from shadow state to active state.
Replay debugging guide maps those decisions to current SDK fields and operator evidence.
Benchmark contract
AllSource publishes a 469K events/sec batch-ingest reference and an 11.9µs p99 indexed-read reference. These are different paths. Neither represents hosted HTTP latency, graph recall, vector retrieval, or synchronous single-event durability under every fsync policy.
cargo run --release -p allsource-performanceBenchmark reproduction guide records hardware, release-mode requirements, and measured stages.
When not to choose an event store
Use a relational or document database as primary storage when current state and ad-hoc joins dominate, history has no product value, and rebuilding views adds ceremony without benefit. Event sourcing imposes event naming, schema evolution, ordering, concurrency, and projection responsibilities. Those costs need replay, provenance, auditability, or temporal reads—not fashion.
