Backend interview prep

Start

Event Sourcing Interview Questions and Answers

Learn Event Sourcing with interview questions, Mermaid diagrams, Spring Boot examples, Kafka integration, CQRS relationship, snapshots, and enterprise production best practices.

Event Sourcing - Interview Questions & Answers

Traditional applications store only the latest state of data.

For example:

Account Balance = $12,000

But they don't tell how the balance became $12,000.

Event Sourcing takes a different approach.

Instead of storing the latest state, it stores every business event that changed the state.

Examples:

  • Account Created
  • Money Deposited
  • Money Withdrawn
  • Interest Added

The current state is rebuilt by replaying these events.

Event Sourcing is widely used in:

  • Banking
  • Financial Trading
  • Insurance
  • Healthcare
  • E-Commerce
  • Audit Systems

Event Sourcing Architecture

flowchart LR

BusinessCommand["Business Command"] --> BusinessService["Business Service"]

BusinessService["Business Service"] --> EventStore["Event Store"]

EventStore["Event Store"] --> EventBus["Event Bus"]

EventBus["Event Bus"] --> Consumers

EventStore["Event Store"] --> StateRebuilder["State Rebuilder"]

StateRebuilder["State Rebuilder"] --> CurrentState["Current State"]

Q1. What is Event Sourcing?

Answer

Event Sourcing is an architectural pattern where every change to application state is stored as an immutable event.

Instead of updating database rows directly, applications append events to an Event Store.

The current state is reconstructed by replaying all events.

Example

Instead of storing:

Balance = $12,000

Store:

Account Created

↓

Deposit $5,000

↓

Deposit $10,000

↓

Withdraw $3,000

↓

Current Balance = $12,000

Event Flow

flowchart TD

Command --> Event

Event --> EventStore["Event Store"]

EventStore["Event Store"] --> CurrentState["Current State"]

Q2. Why do we need Event Sourcing?

Answer

Traditional databases overwrite previous values.

Historical information is lost.

Event Sourcing preserves every business action.

Benefits include:

  • Complete Audit History
  • Event Replay
  • Time Travel
  • Easy Debugging
  • Regulatory Compliance

Traditional Database

flowchart LR

UpdateBalance["Update Balance"] --> OverwriteRecord["Overwrite Record"]

Event Sourcing

flowchart LR

Deposit --> StoreEvent["Store Event"]

Withdraw --> StoreEvent["Store Event"]

Interest --> StoreEvent["Store Event"]

Q3. What is an Event Store?

Answer

An Event Store is a database that stores events sequentially.

Every event is immutable.

Common technologies include:

  • Apache Kafka
  • EventStoreDB
  • PostgreSQL
  • Cassandra
  • DynamoDB

Event Store

flowchart TD

Application --> EventStore["Event Store"]

EventStore["Event Store"] --> Event1["Event 1"]

EventStore["Event Store"] --> Event2["Event 2"]

EventStore["Event Store"] --> Event3["Event 3"]

Best Practice

Events should never be modified after they are stored.

Q4. How is the current state rebuilt?

Answer

The application replays all events in order.

Example:

Account Created

↓

Deposit 1000

↓

Withdraw 200

↓

Deposit 500

↓

Current Balance = 1300

Replay

flowchart LR

EventStore["Event Store"] --> ReplayEvents["Replay Events"]

ReplayEvents["Replay Events"] --> CurrentState["Current State"]

Q5. What are Snapshots?

Answer

Replaying millions of events can become slow.

A Snapshot stores the current state after a certain number of events.

Later replay begins from the snapshot instead of the beginning.

Snapshot Example

Events 1–10,000

↓

Snapshot

↓

Replay Events 10,001+

Snapshot Flow

flowchart TD

Events --> Snapshot

Snapshot --> RemainingEvents["Remaining Events"]

RemainingEvents["Remaining Events"] --> CurrentState["Current State"]

Benefits

  • Faster startup
  • Better performance
  • Reduced replay time

Q6. How does Event Sourcing work with CQRS?

Answer

Event Sourcing and CQRS are often used together.

Workflow:

  1. Command updates aggregate.
  2. Event stored.
  3. Event published.
  4. Read model updated.

CQRS + Event Sourcing

flowchart LR

Command --> WriteModel["Write Model"]

WriteModel["Write Model"] --> EventStore["Event Store"]

EventStore["Event Store"] --> ReadModel["Read Model"]

Interview Tip

CQRS does not require Event Sourcing.

Event Sourcing works very well with CQRS.

Q7. How does Spring Boot implement Event Sourcing?

Answer

Spring Boot applications typically use:

  • Spring Boot
  • Kafka
  • JPA
  • Event Store
  • Spring Cloud Stream

Workflow:

REST API

↓

Command

↓

Aggregate

↓

Event Store

↓

Kafka

↓

Consumers

Spring Boot Architecture

flowchart TD

SpringBoot["Spring Boot"] --> CommandHandler["Command Handler"]

CommandHandler["Command Handler"] --> EventStore["Event Store"]

EventStore["Event Store"] --> Kafka

Kafka --> Consumers

Q8. What are common Event Sourcing mistakes?

Answer

Common mistakes include:

  • Mutable events
  • Missing snapshots
  • Large event payloads
  • No versioning
  • Ignoring replay
  • Tight coupling
  • No idempotency

Wrong Design

Update Database

↓

Overwrite History ❌

Correct Design

Store Event

↓

Replay

↓

Current State ✅

Q9. What are the advantages and disadvantages of Event Sourcing?

Answer

Advantages

  • Complete audit history
  • Replay capability
  • Event-driven architecture
  • Regulatory compliance
  • Easier debugging

Challenges

  • Higher complexity
  • Replay time
  • Snapshot management
  • Event versioning
  • Storage growth

Pros & Cons

mindmap
  root((Event Sourcing))
    Advantages
      Audit
      Replay
      Compliance
      Scalability
    Challenges
      Replay Cost
      Complexity
      Versioning
      Snapshots

Q10. What are the enterprise best practices for Event Sourcing?

Answer

Follow these recommendations:

  • Keep events immutable.
  • Store events sequentially.
  • Use snapshots.
  • Version event schemas.
  • Build replay tools.
  • Monitor event processing.
  • Use idempotent consumers.
  • Separate write and read models.
  • Secure the Event Store.
  • Backup event data regularly.

Enterprise Architecture

flowchart TD

Client --> CommandApi["Command API"]

CommandApi["Command API"] --> Aggregate

Aggregate --> EventStore["Event Store"]

EventStore["Event Store"] --> Kafka

Kafka --> ProjectionService["Projection Service"]

ProjectionService["Projection Service"] --> ReadDatabase["Read Database"]

ReadDatabase["Read Database"] --> QueryApi["Query API"]

Event Processing Pipeline

flowchart LR

Command --> Event

Event --> EventStore["Event Store"]

EventStore["Event Store"] --> Replay

Replay --> CurrentState["Current State"]

Event Sourcing Overview

mindmap
  root((Event Sourcing))
    Event Store
    Replay
    Snapshots
    CQRS
    Kafka
    Immutable Events
    Projections
    Versioning

Traditional CRUD vs Event Sourcing

Traditional CRUD Event Sourcing
Stores latest state Stores every event
Updates records Appends events
Limited audit Complete audit trail
Difficult replay Replay supported
Simple model Higher complexity
Small storage Larger storage

Real-World Banking Example

A savings account maintains every transaction.

Account Created

↓

Deposit ₹50,000

↓

Withdraw ₹5,000

↓

Interest Added ₹1,500

↓

Withdraw ₹10,000

↓

Current Balance = ₹36,500

If corruption occurs, the system simply replays all stored events to rebuild the correct account balance.

Senior Interview Tip

Event Sourcing is ideal when the history of business events is as important as the current state.

A production-ready Event Sourcing platform typically includes:

  • Spring Boot
  • Apache Kafka
  • Event Store
  • CQRS
  • Snapshots
  • Projection Services
  • Schema Registry
  • Event Versioning
  • Dead Letter Queues
  • Replay Services
  • Idempotent Consumers
  • Prometheus & Grafana
  • Distributed Tracing
  • Audit Logging

Remember:

  • CRUD stores the latest state.
  • Event Sourcing stores every state change.
  • The current state is rebuilt by replaying events.
  • Snapshots improve replay performance.

Quick Revision

  • Event Sourcing stores every business event instead of only the latest state.
  • Events are immutable and appended to an Event Store.
  • Current state is rebuilt by replaying stored events.
  • Snapshots reduce replay time for large event streams.
  • Event Sourcing works well with CQRS but is not mandatory for CQRS.
  • Preserve event order and version event schemas.
  • Build replay and projection services.
  • Use idempotent consumers to handle duplicate events safely.
  • Monitor event processing and secure the Event Store.
  • Combine Event Sourcing, Kafka, CQRS, snapshots, and observability for enterprise-grade event-driven systems.