Event Sourcing: How to Explain It in an Interview (2026)

Event sourcing is a pattern where every change to an application’s state is captured as an immutable event and persisted in an append‑only log. Instead of storing the latest value in a row, you store what happened – e.g., "OrderCreated", "ItemAdded", "PaymentReceived". The current state of any entity can be reconstructed by replaying its events from the beginning or from a snapshot.

How Event Sourcing Works

The Event Store

The core component is an event store – a durable, append‑only sequence of events, usually partitioned by aggregate ID (e.g., an order ID). Events are written in a transaction, guaranteeing that either all changes for a command are recorded or none are.

Rehydrating State

When the application needs the current state of an aggregate, it loads its events and folds them into a domain model. Many implementations keep periodic snapshots (e.g., every 1000 events) to avoid replaying the entire history each time.

Write‑Side vs. Read‑Side

The write side (command handling) works directly with events. The read side often uses projections (also called read models) that listen to the event stream and build query‑optimized views, typically stored in a separate database.

Trade‑offs

Concrete Example: An Online Marketplace Order

1. Command: CreateOrder(orderId, buyerId) → Event: OrderCreated(orderId, buyerId, timestamp)
2. Command: AddItem(orderId, sku, qty) → Event: ItemAdded(orderId, sku, qty, timestamp)
3. Command: Pay(orderId, paymentId) → Event: PaymentReceived(orderId, paymentId, amount, timestamp)

The order aggregate rehydrates by applying these three events in order, ending with a state that reflects a paid order with items. A projection might listen to PaymentReceived events and update a “total sales” table used by the finance team.

Typical Interview Questions

1. “Can you define event sourcing in one sentence?” – Answer: “Event sourcing stores every state‑changing action as an immutable event, and the current state is derived by replaying those events.”
2. “Why would you choose event sourcing over a traditional CRUD model?” – Discuss auditability, replayability, and decoupling of write and read models.
3. “How do you handle schema evolution when an event’s structure changes?” – Explain versioned events, up‑casting during replay, or transformation in the projection layer.
4. “What are the performance implications of replaying many events?” – Mention snapshots, event pruning, and the cost‑benefit of read‑side materialized views.
5. “How do you ensure eventual consistency between write and read sides?” – Talk about idempotent projections, at‑least‑once delivery guarantees, and compensating actions.

60‑Second Spoken Version

“Event sourcing is a design where every change to an entity is recorded as an immutable event in an append‑only log. The current state is not stored directly; instead we rebuild it by replaying those events, optionally starting from a recent snapshot. This gives us a complete audit trail and makes it easy to rebuild past states or create new read models. The trade‑offs are increased storage and operational complexity—especially around versioning events and keeping projections in sync. A typical example is an order system: creating an order, adding items, and receiving payment all emit separate events, and a projection updates a sales dashboard in near real‑time. Interviewers will ask you to define it, compare it to CRUD, discuss event versioning, and explain how you handle read‑side performance.”

How to Practice This

1. Write the one‑sentence definition on a sticky note and rehearse it until it feels natural.
2. Walk through the marketplace example aloud, timing yourself to stay under 90 seconds.
3. Use Call Assistant to record your answer, then listen back for filler words and adjust the flow. Replay the recording while a friend asks follow‑up questions to simulate the interview environment.

---

FAQ

• What is the difference between an event and a command? A command is an intention sent to the system (e.g., AddItem), while an event is the fact that something actually happened (ItemAdded). Commands may be rejected; events are immutable records of successful changes.

• Do I need a separate database for projections? Most implementations use a dedicated read store optimized for queries (e.g., a relational table or a NoSQL document). This separation allows the write side to stay simple and performant.

• How do you deal with large event streams? Common strategies include periodic snapshots, archiving older events to cold storage, and pruning events that are no longer needed for business logic.

• Is event sourcing only useful for large systems? Not necessarily. Small services can benefit from auditability and the ability to replay scenarios for debugging, but the added complexity should be justified by the problem domain.