Event sourcing pattern in Kafka - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the Event Sourcing Pattern?

Event Sourcing is a design pattern where all changes to application state are stored as a sequence of events. Instead of saving just the current state, you save every change that happened, so you can rebuild the state anytime by replaying events.

intermediate

How does Kafka help implement Event Sourcing?

Kafka acts as an event store by storing events in topics. Each event is a message in Kafka, which can be replayed to rebuild the state or to trigger other actions. Kafka's durability and ordering make it ideal for event sourcing.

intermediate

What is an aggregate in Event Sourcing?

An aggregate is a cluster of domain objects that can be treated as a single unit. It helps organize events and ensures consistency when applying changes.

beginner

Why is replaying events important in Event Sourcing?

Replaying events means applying all stored events in order to rebuild the current state of an entity. This allows recovery from failures and supports auditing by showing how state evolved over time.

advanced

What is a common challenge when using Event Sourcing with Kafka?

One challenge is handling event versioning. As the system evolves, event formats may change. You need strategies to handle old and new event versions to keep the system working smoothly.

What does Event Sourcing store in Kafka?

A A sequence of events representing all changes

B Only the latest state snapshot

C User login credentials

D Database schema definitions

Event Sourcing stores every change as an event, so Kafka holds a sequence of these events.

Why is Kafka suitable for Event Sourcing?

A Because it automatically deletes old events

B Because it only supports real-time data

C Because it stores events durably and in order

D Because it encrypts all messages by default

Kafka keeps events durable and ordered, which is essential for replaying events correctly.

What is the purpose of replaying events in Event Sourcing?

A To rebuild the current state from past changes

B To delete old data

C To speed up database queries

D To send notifications to users

Replaying events applies all changes in order to reconstruct the current state.

What is an aggregate in Event Sourcing?

A A database index

B A group of related events representing one entity

C A type of Kafka topic

D A user interface component

An aggregate groups events that belong to the same entity or concept.

What problem does event versioning solve?

A Filtering events by user

B Encrypting events for security

C Compressing events to save space

D Handling changes in event formats over time

Event versioning manages how to handle old and new event formats as the system evolves.

Explain how Event Sourcing works and why Kafka is a good fit for it.

Think about saving every change and how Kafka keeps messages.

Describe the role of aggregates and event versioning in Event Sourcing.

Consider how events are organized and how changes over time are managed.

Practice

1. What is the main purpose of the event sourcing pattern in Kafka?

easy

A. To save every change as an event for a full history

B. To delete old data to save storage space

C. To process only the latest state without history

D. To send events only to one consumer

Solution

1. Step 1: Understand event sourcing concept

   Event sourcing means saving every change as a separate event instead of just the current state.

2. Step 2: Relate to Kafka usage

   Kafka topics store these events so consumers can read the full history and rebuild state if needed.

3. Final Answer:

   To save every change as an event for a full history -> Option A

4. Quick Check:

   Event sourcing = full history saved as events [OK]

Hint: Event sourcing always stores all changes, not just current state [OK]

Common Mistakes:

• Thinking event sourcing deletes old data
• Believing it only keeps latest state
• Assuming events go to only one consumer

2. Which Kafka component is primarily used to store events in event sourcing?

easy

A. Kafka Topic

B. Kafka Producer

C. Kafka Consumer

D. Kafka Broker

Solution

1. Step 1: Identify Kafka components roles

   Kafka Producer sends data, Consumer reads data, Broker manages servers, Topic stores data.

2. Step 2: Match storage role

   Events are stored in Kafka Topics, which keep the event log for consumers.

3. Final Answer:

   Kafka Topic -> Option A

4. Quick Check:

   Events stored in Kafka Topic [OK]

Hint: Events are stored in topics, not producers or consumers [OK]

Common Mistakes:

• Confusing producer with storage
• Thinking consumer stores events
• Mixing broker with event storage

3. Given this Kafka event stream, what will the consumer state be after processing all events?

events = [
  {"type": "create", "id": 1, "value": 10},
  {"type": "update", "id": 1, "value": 20},
  {"type": "create", "id": 2, "value": 5},
  {"type": "delete", "id": 1}
]

state = {}
for event in events:
    if event["type"] == "create" or event["type"] == "update":
        state[event["id"]] = event["value"]
    elif event["type"] == "delete":
        state.pop(event["id"], None)

print(state)

medium

A. {}

B. {"1": 20, "2": 5}

C. {"1": 10, "2": 5}

D. {"2": 5}

Solution

1. Step 1: Process each event in order

   First create id 1 with value 10, then update id 1 to 20, create id 2 with 5, then delete id 1.

2. Step 2: Determine final state

   After deletion, id 1 is removed, only id 2 with value 5 remains.

3. Final Answer:

   {"2": 5} -> Option D

4. Quick Check:

   Delete removes id 1, only id 2 left [OK]

Hint: Track events step-by-step to update state correctly [OK]

Common Mistakes:

• Forgetting the delete event removes id 1
• Confusing update with create
• Assuming old values remain after update

4. Identify the bug in this Kafka event consumer code snippet for event sourcing:

state = {}
for event in events:
    if event["type"] == "create":
        state[event["id"]] = event["value"]
    elif event["type"] == "update":
        if event["id"] in state:
            state[event["id"]] = event["value"]
    elif event["type"] == "delete":
        del state[event["id"]]

medium

A. Missing else clause for unknown event types

B. Using del without checking if id exists causes KeyError

C. Create should not overwrite existing id

D. Update should create new id if not present

Solution

1. Step 1: Analyze delete operation

   Using del without checking if the key exists can cause a KeyError if id is missing.

2. Step 2: Check other conditions

   Update correctly checks if id exists before updating; create overwrites which is allowed; else clause is optional.

3. Final Answer:

   Using del without checking if id exists causes KeyError -> Option B

4. Quick Check:

   del without check = KeyError risk [OK]

Hint: Always check key exists before deleting from dict [OK]

Common Mistakes:

• Ignoring KeyError on delete
• Thinking update must create new id
• Believing create cannot overwrite

5. You want to rebuild the current state from a Kafka topic storing events using event sourcing. Which approach is best to handle a large number of events efficiently?

hard

A. Read all events from the beginning every time to rebuild state

B. Only read the latest event for each entity from the topic

C. Use snapshots periodically and then replay only recent events

D. Delete old events from the topic to reduce size

Solution

1. Step 1: Understand rebuilding state from events

   Replaying all events from the start is slow for large data; deleting events loses history.

2. Step 2: Use snapshots to optimize

   Snapshots save a recent state, so only new events after snapshot need replay, improving efficiency.

3. Final Answer:

   Use snapshots periodically and then replay only recent events -> Option C

4. Quick Check:

   Snapshots + replay recent events = efficient rebuild [OK]

Hint: Snapshots speed up rebuilding by avoiding full replay [OK]

Common Mistakes:

• Replaying all events every time (slow)
• Deleting events loses full history
• Reading only latest event misses changes