What is event sourcing and how does it relate to microservices?
Learn what event sourcing is, how state is rebuilt by replaying immutable events, its link to CQRS and microservices, benefits and trade-offs.
Expected Interview Answer
Event sourcing is a pattern where you store every change to application state as an immutable sequence of events, and reconstruct current state by replaying those events rather than saving only the latest snapshot.
Instead of updating a row in place, each state change is appended to an event log as a fact (for example OrderPlaced, ItemShipped). The current state is derived by replaying events, and you can rebuild any past state or new read models from the same log. In microservices it pairs naturally with event-driven communication: services publish domain events that others consume, giving loose coupling, a full audit trail, and support for CQRS read projections. Its costs are added complexity, schema/versioning of events, and eventual consistency.
- Complete audit trail of every state change
- Ability to rebuild state or new read models by replaying events
- Natural fit for event-driven, loosely coupled microservices
- Time-travel debugging and temporal queries
- Decouples services through published domain events
AI Mentor Explanation
Think of a full ball-by-ball commentary log instead of just the final scorecard. Every delivery, run, and wicket is recorded as it happened, so you can replay the innings to any point and reconstruct the exact score. The current total is just the sum of every recorded event, and you never lose the story of how you got there.
Step-by-Step Explanation
Step 1
Capture events
Represent each state change as an immutable domain event with a clear name and payload.
Step 2
Append to the log
Store events in an append-only event store rather than updating rows in place.
Step 3
Rebuild state
Reconstruct current state by replaying the ordered events for an aggregate.
Step 4
Snapshot for speed
Periodically save snapshots so replay does not start from the very first event each time.
Step 5
Project read models
Consume events to build denormalized read models, often as the query side of CQRS.
Step 6
Publish across services
Emit events to other microservices so they react and stay loosely coupled.
What Interviewer Expects
- Understanding that events, not current state, are the source of truth
- How current state is rebuilt by replaying events
- Relationship to CQRS and read-model projections
- How it enables event-driven, loosely coupled microservices
- Awareness of event versioning and eventual consistency challenges
Common Mistakes
- Confusing event sourcing with simply publishing events on a queue
- Storing current state instead of the sequence of changes
- Ignoring event schema evolution and versioning over time
- Forgetting snapshots, making replay slow for long-lived aggregates
- Assuming strong consistency instead of designing for eventual consistency
Best Answer (HR Friendly)
“Event sourcing means saving every change that happens as a permanent record, then figuring out the current situation by replaying all those changes. It gives you a full history and works well with microservices that talk to each other through events, but it is more complex than just saving the latest value.”
Code Example
type Event =
| { type: 'OrderPlaced'; items: string[] }
| { type: 'ItemShipped'; item: string }
function rebuild(events: Event[]) {
const state = { pending: new Set<string>(), shipped: new Set<string>() }
for (const e of events) {
if (e.type === 'OrderPlaced') e.items.forEach(i => state.pending.add(i))
if (e.type === 'ItemShipped') {
state.pending.delete(e.item)
state.shipped.add(e.item)
}
}
return state // current state derived purely from the event log
}Follow-up Questions
- How does event sourcing combine with CQRS?
- How do you handle event schema versioning over time?
- What are snapshots and why do you need them?
- How do you keep replay performant for long-lived aggregates?
- What are the downsides of event sourcing in a microservices system?
MCQ Practice
1. In event sourcing, what is stored as the source of truth?
Event sourcing persists every change as an event; current state is derived by replaying them.
2. Why are snapshots used in event sourcing?
Snapshots capture state at a point so replay can start from there instead of the first event.
3. Event sourcing pairs most naturally with which pattern?
Events from the write side are projected into read models, which is exactly the CQRS query side.
Flash Cards
What is stored in event sourcing? — An append-only, immutable sequence of domain events representing every state change.
How is current state obtained? — By replaying the ordered events for an aggregate (optionally from a snapshot).
Why use snapshots? — To speed up rebuilding state without replaying the entire event history each time.
How does it help microservices? — Services publish and consume domain events, giving loose coupling and an audit trail.
Continue Learning
Related Interview Questions
What is the CQRS pattern and when should you use it?
medium
A service needs data owned by another service on almost every request. Do you call it, cache it, or copy it into a read model?
hard
What is Event Sourcing and How Does It Differ From Storing Current State?
hard
What is CQRS (Command Query Responsibility Segregation)?
hard