Event sourcing pattern in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Kafka event sourcing consumer code?

Consider a Kafka consumer that reads events from a topic and reconstructs the current state by applying all events in order. What will be the final state printed?

Kafka

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer('user-events', bootstrap_servers='localhost:9092', auto_offset_reset='earliest')

state = {}
for message in consumer:
    event = json.loads(message.value)
    if event['type'] == 'UserCreated':
        state[event['user_id']] = {'name': event['name'], 'active': True}
    elif event['type'] == 'UserDeactivated':
        if event['user_id'] in state:
            state[event['user_id']]['active'] = False
    if len(state) == 2:
        break
print(state)

A {"u1": {"name": "Alice", "active": true}, "u2": {"name": "Bob", "active": true}}

B {"u1": {"name": "Alice", "active": false}, "u2": {"name": "Bob", "active": true}}

C {"u1": {"name": "Alice", "active": true}}

D SyntaxError

💡 Hint

Remember that events are applied in order and can change the state of existing users.

The consumer reads events in order. First, UserCreated for u1 (Alice) sets active true. Then UserDeactivated for u1 sets active false. Then UserCreated for u2 (Bob) sets active true. So final state has u1 inactive and u2 active.

🧠 Conceptual

intermediate

Which statement best describes event sourcing in Kafka?

Choose the statement that correctly explains the event sourcing pattern using Kafka.

A Event sourcing stores only the latest state snapshot in Kafka topics to reduce storage.

B Event sourcing uses Kafka to send commands directly to update the database state.

C Event sourcing requires Kafka to delete old events after processing to save space.

D Event sourcing stores all changes as events in Kafka topics, allowing state reconstruction by replaying events.

💡 Hint

Think about how event sourcing preserves history.

Event sourcing means storing every change as an event. Kafka topics hold these events, so the current state can be rebuilt by replaying them.

🔧 Debug

advanced

Why does this Kafka event sourcing consumer code raise an error?

Identify the cause of the error in this Kafka consumer code snippet that processes events for state reconstruction.

Kafka

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer('orders', bootstrap_servers='localhost:9092', auto_offset_reset='earliest')

state = {}
for message in consumer:
    event = json.loads(message.value)
    if event['type'] == 'OrderPlaced':
        state[event['order_id']] = event['details']
    elif event['type'] == 'OrderCancelled':
        del state[event['order_id']]
print(state)

A KeyError when deleting a non-existent order_id in state

B JSONDecodeError due to invalid JSON in message.value

C KafkaConsumer raises TimeoutError due to no messages

D TypeError because event['details'] is not a dictionary

💡 Hint

Check what happens if an OrderCancelled event arrives for an order_id not in state.

If the code tries to delete an order_id that was never added, Python raises a KeyError because the key does not exist in the dictionary.

📝 Syntax

advanced

Which Kafka consumer code snippet correctly applies event sourcing to update user balances?

Choose the code snippet that correctly updates user balances by applying 'Deposit' and 'Withdrawal' events from Kafka.

A

for msg in consumer:
    event = json.loads(msg.value)
    if event['type'] == 'Deposit':
        state[event['user_id']] +=+ event['amount']
    elif event['type'] == 'Withdrawal':
        state[event['user_id']] -=- event['amount']

B

for msg in consumer:
    event = json.loads(msg.value)
    if event['type'] == 'Deposit':
        state[event['user_id']] =+ event['amount']
    elif event['type'] == 'Withdrawal':
        state[event['user_id']] =- event['amount']

C

for msg in consumer:
    event = json.loads(msg.value)
    if event['type'] == 'Deposit':
        state[event['user_id']] = state.get(event['user_id'], 0) + event['amount']
    elif event['type'] == 'Withdrawal':
        state[event['user_id']] = state.get(event['user_id'], 0) - event['amount']

D

for msg in consumer:
    event = json.loads(msg.value)
    if event['type'] == 'Deposit':
        state[event['user_id']] += event['amount']
    elif event['type'] == 'Withdrawal':
        state[event['user_id']] -= event['amount']

💡 Hint

Check for correct use of operators and handling missing keys.

Option C correctly initializes missing keys with 0 and uses += and -= logic properly. Options B and D have invalid operators (=+ and +=+), and C does not handle missing keys causing KeyError.

🚀 Application

expert

How many events are stored in Kafka to reconstruct the state after these operations?

A system uses Kafka for event sourcing. The following events are produced in order:
1. UserCreated (user_id: u1)
2. UserUpdated (user_id: u1, name changed)
3. UserDeactivated (user_id: u1)
4. UserCreated (user_id: u2)
5. UserDeleted (user_id: u1)

How many events must be replayed from Kafka to reconstruct the current state of all users?

A 5

B 4

C 3

D 2

💡 Hint

Event sourcing requires replaying all events to get the current state.

All 5 events are stored and must be replayed in order to reconstruct the current state, even if some events delete or deactivate users.

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