What is Event Sourcing
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
Understanding Event Sourcing in Depth
Practical Examples of Event Sourcing Implementation
Common Challenges in Event Sourcing
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.
Try the live tool that powered this guide
Free plan — 20 monitors, 5-minute checks, no card required. Upgrade for 1-minute interval and multi-region monitoring.