CQRS pattern in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of Kafka message flow in CQRS

Given the following Kafka producer and consumer setup in a CQRS pattern, what will be the output printed by the consumer?

Kafka

from kafka import KafkaProducer, KafkaConsumer
import json

producer = KafkaProducer(bootstrap_servers='localhost:9092', value_serializer=lambda v: json.dumps(v).encode('utf-8'))
consumer = KafkaConsumer('write_topic', bootstrap_servers='localhost:9092', value_deserializer=lambda m: json.loads(m.decode('utf-8')))

# Producer sends a command
producer.send('write_topic', {'command': 'create_order', 'order_id': 123})
producer.flush()

# Consumer reads the command
for message in consumer:
    print(f"Received command: {message.value['command']} with order_id {message.value['order_id']}")
    break

A Received command: create_order with order_id None

B Received command: create_order with order_id '123'

C No output, consumer times out

D Received command: create_order with order_id 123

💡 Hint

Remember that JSON serialization converts integers as numbers, not strings.

The producer sends a JSON message with order_id as an integer 123. The consumer deserializes it back to a Python dict with order_id as int. So the printed output shows 123 without quotes.

🧠 Conceptual

intermediate

CQRS pattern separation of concerns

In a CQRS pattern using Kafka, which statement best describes the role of the write and read sides?

A The write side handles queries; the read side handles commands and updates state.

B The write side handles commands and updates state; the read side handles queries and returns data.

C Both write and read sides handle commands and queries interchangeably.

D The write side only stores data; the read side only deletes data.

💡 Hint

Think about separating responsibilities for updating and reading data.

CQRS stands for Command Query Responsibility Segregation. Commands change state (write side), queries read state (read side).

🔧 Debug

advanced

Identify the error in Kafka consumer code for CQRS read model

What error will this Kafka consumer code produce when trying to read from the 'read_topic' in a CQRS pattern? consumer = KafkaConsumer('read_topic', bootstrap_servers='localhost:9092') for message in consumer: data = message.value print(f"Read model data: {data['id']}")

Kafka

consumer = KafkaConsumer('read_topic', bootstrap_servers='localhost:9092')
for message in consumer:
    data = message.value
    print(f"Read model data: {data['id']}")

A KeyError: 'id'

B KafkaTimeoutError: Failed to fetch messages

C TypeError: 'bytes' object is not subscriptable

D No error, prints the id correctly

💡 Hint

Check how KafkaConsumer returns message values by default.

By default, KafkaConsumer returns message.value as bytes. Accessing data['id'] causes TypeError because bytes are not subscriptable like dicts.

📝 Syntax

advanced

Correct Kafka producer code for sending a command in CQRS

Which option is the correct Kafka producer code snippet to send a command message with key 'order-1' and value {'action': 'update', 'order_id': 1} in CQRS?

A producer.send('commands', key=b'order-1', value=json.dumps({'action': 'update', 'order_id': 1}).encode('utf-8'))

B producer.send('commands', key='order-1', value=json.dumps({'action': 'update', 'order_id': 1}))

C producer.send('commands', key=b'order-1', value={'action': 'update', 'order_id': 1})

D producer.send('commands', key='order-1', value={'action': 'update', 'order_id': 1})

💡 Hint

Kafka keys and values must be bytes; JSON strings must be encoded.

Kafka producer expects key and value as bytes. Option A correctly encodes JSON string to bytes and uses bytes key.

🚀 Application

expert

Designing event sourcing with CQRS and Kafka

You want to implement event sourcing with CQRS using Kafka. Which approach correctly ensures that all state changes are captured and read models are updated asynchronously?

A Write side produces events to a Kafka topic; read side consumes events and updates read models asynchronously.

B Both write and read sides produce and consume events from the same Kafka topic simultaneously.

C Write side updates database directly; read side queries database without Kafka involvement.

D Read side produces events to Kafka; write side consumes events and updates state synchronously.

💡 Hint

Think about how event sourcing captures changes and how read models stay updated.

In event sourcing with CQRS, the write side produces events representing state changes. The read side consumes these events asynchronously to update read models, ensuring eventual consistency.

Practice

1. What is the main idea behind the CQRS pattern in Kafka-based systems?

easy

A. Separating commands (writes) and queries (reads) into different parts

B. Using a single topic for both commands and queries

C. Storing all data in one database without separation

D. Ignoring events and focusing only on commands

Solution

1. Step 1: Understand CQRS basics

   CQRS stands for Command Query Responsibility Segregation, which means separating write and read operations.

2. Step 2: Apply to Kafka context

   In Kafka, commands and queries are handled separately, often using different topics for clarity and scalability.

3. Final Answer:

   Separating commands (writes) and queries (reads) into different parts -> Option A

4. Quick Check:

   CQRS = Separate commands and queries [OK]

Hint: Remember CQRS splits writes and reads separately [OK]

Common Mistakes:

• Thinking commands and queries share the same topic
• Confusing CQRS with event sourcing
• Assuming CQRS means no events are used

2. Which Kafka topic setup correctly follows the CQRS pattern?

easy

A. One topic for all commands, events, and queries

B. One topic for commands and a separate topic for events

C. Multiple topics for queries only

D. No topics, just direct database writes

Solution

1. Step 1: Recall CQRS topic separation

   CQRS uses separate topics for commands (writes) and events (results of commands) to keep communication clear.

2. Step 2: Evaluate options

   One topic for commands and a separate topic for events correctly separates commands and events into different topics, matching CQRS principles.

3. Final Answer:

   One topic for commands and a separate topic for events -> Option B

4. Quick Check:

   Separate topics for commands and events = One topic for commands and a separate topic for events [OK]

Hint: Separate commands and events into different topics [OK]

Common Mistakes:

• Mixing commands and queries in one topic
• Ignoring event topics
• Using no Kafka topics at all

3. Given this Kafka setup for CQRS:

commands_topic = ['CreateOrder', 'UpdateOrder']
events_topic = ['OrderCreated', 'OrderUpdated']

Which topic should a read service subscribe to for query data?

medium

A. commands_topic

B. Both commands_topic and events_topic

C. events_topic

D. Neither, it reads directly from the database

Solution

1. Step 1: Identify read service role

   Read services in CQRS listen to events that represent state changes, not commands which are requests.

2. Step 2: Match topic to read service

   Events_topic contains 'OrderCreated' and 'OrderUpdated' which reflect changes; read service subscribes here.

3. Final Answer:

   events_topic -> Option C

4. Quick Check:

   Read service subscribes to events_topic [OK]

Hint: Reads listen to events, not commands [OK]

Common Mistakes:

• Subscribing read service to commands_topic
• Subscribing to both topics unnecessarily
• Assuming reads bypass Kafka

4. You have this Kafka CQRS code snippet:

producer.send('commands', 'CreateOrder')
consumer.subscribe(['commands', 'events'])

What is the main problem here?

medium

A. Consumer should not subscribe to both 'commands' and 'events' topics

B. Producer should send to 'events' topic, not 'commands'

C. Producer must send JSON, not strings

D. Consumer must subscribe only to 'commands' topic

Solution

1. Step 1: Understand CQRS topic roles

   Commands topic is for writes; events topic is for read updates. Consumers usually subscribe to one role.

2. Step 2: Analyze consumer subscription

   Subscribing to both commands and events mixes responsibilities and can cause confusion or errors.

3. Final Answer:

   Consumer should not subscribe to both 'commands' and 'events' topics -> Option A

4. Quick Check:

   Consumer subscribes to one topic type only [OK]

Hint: Consumers should subscribe to either commands or events, not both [OK]

Common Mistakes:

• Thinking producer must send events on commands topic
• Assuming consumer can handle both topics safely
• Ignoring message format requirements

5. How can you design a Kafka-based CQRS system to handle high read traffic without slowing down writes?

hard

A. Use only one consumer group for both commands and events

B. Combine commands and events in one topic to reduce overhead

C. Write all data directly to the database and skip Kafka for reads

D. Use separate Kafka topics for commands and events, and scale read consumers independently

Solution

1. Step 1: Apply CQRS scalability principle

   Separating commands and events allows independent scaling of write and read sides.

2. Step 2: Design Kafka topics and consumers

   Using separate topics for commands and events lets read consumers scale without affecting write performance.

3. Final Answer:

   Use separate Kafka topics for commands and events, and scale read consumers independently -> Option D

4. Quick Check:

   Separate topics and scale reads independently [OK]

Hint: Separate topics and scale read consumers for high traffic [OK]

Common Mistakes:

• Combining commands and events causing bottlenecks
• Skipping Kafka for reads losing scalability
• Using one consumer group for all messages