Event sourcing pattern in Kafka - Deep Dive

Overview - Event sourcing pattern

What is it?

Event sourcing is a way to store data by saving every change as a sequence of events instead of just the current state. Each event represents a fact that happened in the system. This lets you rebuild the current state anytime by replaying all events in order. It is often used with Kafka, a tool that handles streams of events efficiently.

Why it matters

Without event sourcing, systems only keep the latest data, losing the history of how that data changed. This makes it hard to track bugs, audit actions, or recover lost data. Event sourcing solves this by keeping a full history, making systems more reliable, transparent, and easier to fix when problems happen.

Where it fits

Before learning event sourcing, you should understand basic data storage and messaging systems like Kafka. After mastering event sourcing, you can explore related patterns like CQRS (Command Query Responsibility Segregation) and stream processing for building scalable, reactive systems.

Mental Model

Core Idea

Event sourcing stores every change as an immutable event, letting you rebuild the current state by replaying these events in order.

Think of it like...

Imagine writing a diary where you record every action you take each day instead of just writing your current mood. Later, you can read the diary from the start to understand how you got to your current mood.

┌───────────────┐
│ Event Store   │
│ (Kafka Topic) │
└──────┬────────┘
       │
       ▼
┌───────────────┐      ┌───────────────┐
│ Replay Events │─────▶│ Current State │
│ in order      │      │ (Rebuilt)     │
└───────────────┘      └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding events as facts

Concept: Events represent facts or changes that happened in the system, not just data snapshots.

An event is a record of something that happened, like 'UserCreated' or 'OrderPlaced'. Each event is immutable, meaning once saved, it never changes. This differs from traditional databases that overwrite data.

Result

You start thinking of data as a timeline of facts, not just a current snapshot.

Understanding that events are facts helps you see why storing them preserves history perfectly.

2

Foundation

Event store as the single source

Concept: All events are stored in one place, called the event store, which acts as the system's truth.

Instead of updating a database row, you append new events to the event store. This store is append-only and keeps every event forever. Kafka topics are often used as event stores because they handle ordered, durable event streams.

Result

You have a complete, ordered log of all changes that ever happened.

Knowing the event store is the single source of truth changes how you design data flow and recovery.

3

Intermediate

Rebuilding state by replaying events

🤔Before reading on: do you think the current state is stored separately or rebuilt from events? Commit to your answer.

Concept: The current state is not stored directly but rebuilt by applying all events in order.

To get the current state, you start from an empty state and apply each event one by one. For example, applying 'UserCreated' then 'UserNameChanged' events will give you the latest user info. This replay can happen anytime to recover or audit state.

Result

You can reconstruct the exact current state at any time from the event history.

Understanding replaying events explains how event sourcing supports full audit and recovery.

4

Intermediate

Using Kafka for event sourcing

🤔Before reading on: do you think Kafka stores events permanently or deletes them after processing? Commit to your answer.

Concept: Kafka stores events durably and in order, making it a natural fit for event sourcing.

Kafka topics keep events in partitions with offsets, preserving order. Consumers can replay events by reading from any offset. Kafka's durability and scalability make it ideal for event sourcing in distributed systems.

Result

You can build systems that reliably store and replay events at scale.

Knowing Kafka's design helps you leverage its strengths for event sourcing.

5

Intermediate

Snapshotting to optimize replay

Concept: To avoid replaying all events from the start, systems create snapshots of state at points in time.

Snapshots save the current state after many events. When rebuilding, you start from the latest snapshot and replay only newer events. This speeds up recovery and reduces load.

Result

Rebuilding state becomes faster and more efficient.

Understanding snapshots balances full history with practical performance.

6

Advanced

Handling event schema evolution

🤔Before reading on: do you think event formats can change freely without issues? Commit to your answer.

Concept: Event formats must evolve carefully to keep old and new events compatible.

As systems grow, event schemas change (adding fields, renaming). Using schema registries and versioning ensures consumers can read old and new events without errors. This avoids breaking the replay process.

Result

Your event sourcing system remains stable despite changes over time.

Knowing schema evolution prevents costly downtime and data loss.

7

Expert

Event sourcing tradeoffs and pitfalls

🤔Before reading on: do you think event sourcing always simplifies system design? Commit to your answer.

Concept: Event sourcing adds complexity and requires careful design to avoid pitfalls.

While event sourcing offers auditability and recovery, it complicates querying current state and debugging. Developers must handle eventual consistency, complex event ordering, and storage growth. Choosing when to use it depends on system needs.

Result

You gain a balanced view of event sourcing's benefits and costs.

Understanding tradeoffs helps you apply event sourcing wisely, avoiding misuse.

Under the Hood

Event sourcing systems append each event to an immutable log stored in an event store like Kafka. Each event has a unique offset and timestamp, ensuring order. Consumers read events sequentially, applying them to build or update state. Kafka's partitioning and replication ensure durability and scalability. Snapshots store intermediate states to optimize replay. Schema registries manage event format versions to maintain compatibility.

Why designed this way?

Event sourcing was designed to solve problems of lost history and difficult recovery in traditional databases. By storing immutable events, systems gain full audit trails and can recover from failures by replaying events. Kafka was chosen for its high-throughput, ordered, and durable event storage, fitting event sourcing needs better than traditional databases. The design balances immutability, scalability, and fault tolerance.

┌───────────────┐
│ Event Producer│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Kafka Topic   │
│ (Event Store) │
└──────┬────────┘
       │
       ▼
┌───────────────┐      ┌───────────────┐
│ Event Consumer│─────▶│ State Builder │
│ (Replayer)    │      │ (Applies     │
└───────────────┘      │ events to    │
                       │ build state) │
                       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does event sourcing mean storing only the latest state? Commit yes or no.

Common Belief: Event sourcing just stores the current state like a normal database.

Reality: Event sourcing stores every change as an immutable event, not just the latest state.

Why it matters: Believing this causes confusion about how to recover history or audit changes, leading to wrong implementations.

Quick: Can you freely change event formats without issues? Commit yes or no.

Common Belief: You can change event formats anytime without affecting the system.

Reality: Event formats must be versioned and managed carefully to keep backward compatibility.

Why it matters: Ignoring this breaks event replay and causes system failures.

Quick: Does event sourcing always simplify querying data? Commit yes or no.

Common Belief: Event sourcing makes querying data simpler because all history is stored.

Reality: Querying current state can be complex and often requires additional projections or snapshots.

Why it matters: Assuming simple queries leads to performance problems and complex code.

Quick: Is event sourcing suitable for every application? Commit yes or no.

Common Belief: Event sourcing is the best pattern for all data storage needs.

Reality: Event sourcing adds complexity and is best for systems needing auditability and recovery, not simple CRUD apps.

Why it matters: Misapplying event sourcing wastes resources and complicates simple systems.

Expert Zone

1

Event ordering in distributed systems can be tricky; understanding Kafka partitions and keys is crucial to maintain correct event sequences.

2

Snapshot frequency is a tradeoff: too frequent wastes storage, too rare slows recovery; tuning depends on system load and event volume.

3

Event sourcing requires careful handling of eventual consistency, especially when multiple services consume and react to events asynchronously.

When NOT to use

Avoid event sourcing for simple applications with minimal audit needs or where immediate consistency is critical. Use traditional CRUD databases or caching layers instead. Also, if event volume is low and history is not important, event sourcing adds unnecessary complexity.

Production Patterns

In production, event sourcing is combined with CQRS to separate read and write models, using Kafka for event storage and stream processing frameworks like Kafka Streams or ksqlDB for projections. Snapshots are stored in fast-access databases to speed up state rebuilds. Schema registries manage event versions to ensure smooth upgrades.

Connections

Command Query Responsibility Segregation (CQRS)

Builds-on

Knowing event sourcing helps understand CQRS, which separates commands (writes) from queries (reads) to optimize system performance.

Immutable Ledger in Blockchain

Same pattern

Both event sourcing and blockchain store immutable sequences of events or transactions, ensuring full history and auditability.

Version Control Systems (e.g., Git)

Similar pattern

Like event sourcing, version control records every change as a commit, allowing you to replay history and understand how the current state evolved.

Common Pitfalls

#1 Replaying all events from the start every time causes slow recovery.

Wrong approach:

On system restart, replay all events from offset 0 without snapshots.

Correct approach:

Use snapshots to start replay from the latest saved state, then apply only newer events.

Root cause:

Not using snapshots ignores performance optimization, making recovery inefficient.

#2 Changing event schema without versioning breaks consumers.

Wrong approach:

Modify event JSON structure directly without schema registry or version control.

Correct approach:

Use a schema registry and version events to maintain backward compatibility.

Root cause:

Lack of schema management causes incompatible event formats and runtime errors.

#3 Treating event sourcing as a simple database replacement without adjusting queries.

Wrong approach:

Query current state directly from event store without projections or snapshots.

Correct approach:

Build read models or projections optimized for queries, separate from event store.

Root cause:

Misunderstanding event sourcing's separation of write and read concerns leads to poor performance.

Key Takeaways

Event sourcing stores every change as an immutable event, preserving full history and enabling state reconstruction.

Kafka is a powerful tool for event sourcing because it stores ordered, durable event streams that can be replayed anytime.

Snapshots optimize performance by saving intermediate states, reducing the need to replay all events from the start.

Careful schema management is essential to evolve events without breaking consumers or replay processes.

Event sourcing adds complexity and is best used when auditability, recovery, and history are critical requirements.