What is Event Sourcing
Key idea:
Event Sourcing — pattern where current state is derived from a sequence of immutable events stored in an event log. Instead of UPDATE user SET balance = 100, write BalanceCredited {amount: 100}. Benefits: full audit trail, time-travel queries, state rebuild. Costs: tricky schema migrations, eventual consistency, "upcasting" old events as schemas evolve.
Below: details, example, related terms, FAQ.
Details
- Append-only log: events immutable, order matters
- Event store: EventStore DB, Kafka, Postgres tables
- Snapshots: for performance — periodic state dump
- Projections: read models built from event stream
- Upcasters: transform old event versions into new
Example
// Events append
EventStore.append('order-123', [
OrderCreated { customerId, items }
OrderConfirmed { timestamp }
OrderShipped { trackingNumber }
])
// Rebuild state by replaying events
state = fold(events, initialState, applyEvent)Related Terms
Learn more
Frequently Asked Questions
Is Event Sourcing only for CQRS?
No, but often combined. ES gives write-side, CQRS separates read and write models.
How to deal with schema changes?
Upcasters: at read time, transform old event versions to new schema. Or versioned event types (OrderCreated_V1, V2).
Storage size — a problem?
Events grow linearly. For long-lived streams — snapshots every N events. Or archive old events to cold storage.