Event Sourcing
Event sourcing is an architecture where a system stores the sequence of events that happened — not just the current state — and derives current state by replaying or projecting those events, so history is the source of truth.
Most applications store current state directly: a row in a database represents "how things are right now," and an update overwrites what was there before. That's simple, but it means the history of how things got to their current state is either lost or has to be reconstructed from a separate, easy-to-forget audit log bolted on afterward.
Event sourcing inverts the relationship: the durable record is the sequence of events (a message was sent, a decision was logged, an approval was granted), and current state is a derived view — computed by replaying those events, or maintained as a continuously updated "projection" of them. The event log becomes the actual source of truth; everything else is a materialized view of it.
The architecture pays off in a few specific ways: a complete, naturally ordered history exists without extra bookkeeping, projections can be rebuilt or added later without losing information, and "what happened, in what order" is a first-class query rather than something reconstructed from timestamps on mutable rows. The cost is added complexity — designing events well, and building the projection machinery, is real engineering work most CRUD applications skip.
Event Sourcing, in the product
Aanty's kernel is event-sourced: typed messages and their state changes are the durable event log, and views like the current message state, the decision ledger, and the needs-you queue are projections built from it. That's what makes the append-only audit trail a natural consequence of the architecture rather than a separate system to keep in sync.
Related terms and pages
See Event Sourcing in a real workspace
Bring a channel from wherever your team works today. In fifteen minutes we'll show what event sourcing looks like on a real conversation, not a slide.