Why event-driven scales applications in Kafka - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does event-driven architecture improve scalability?

In event-driven systems like Kafka, what is the main reason they scale better than traditional request-response systems?

A Because event-driven systems use a single thread to handle all events, reducing complexity.

B Because events are always processed in a strict order, preventing any parallelism.

C Because events are processed asynchronously, allowing many consumers to work in parallel without waiting.

D Because events are stored in a database and processed only when requested synchronously.

💡 Hint

Think about how events flow and how consumers handle them in parallel.

Event-driven systems decouple producers and consumers. Consumers can process events independently and in parallel, which improves scalability.

❓ Predict Output

intermediate

Output of Kafka consumer processing events asynchronously

What will be the output of this simplified Kafka consumer code snippet that processes events asynchronously?

Kafka

import asyncio

async def process_event(event):
    await asyncio.sleep(0.1)
    print(f"Processed {event}")

async def main():
    events = ['e1', 'e2', 'e3']
    tasks = [process_event(e) for e in events]
    await asyncio.gather(*tasks)

asyncio.run(main())

A Processed e1\nProcessed e2\nProcessed e3 (always in this order)

B Processed e1\nProcessed e2\nProcessed e3 (order may vary due to async)

C SyntaxError due to missing await in list comprehension

D RuntimeError because asyncio.gather cannot handle multiple tasks

💡 Hint

Consider how async tasks run concurrently and the order of print statements.

The events are processed concurrently, so the print order may vary. The code runs without errors.

🔧 Debug

advanced

Identify the scalability issue in this Kafka consumer code

What is the main scalability problem in this Kafka consumer code snippet?

Kafka

from kafka import KafkaConsumer

consumer = KafkaConsumer('topic')
for message in consumer:
    print(f"Processing {message.value}")
    # Simulate long processing
    import time
    time.sleep(5)

A The consumer processes messages one by one and blocks, limiting throughput.

B The consumer does not commit offsets, causing duplicate processing.

C The consumer uses too many threads, causing overhead.

D The consumer subscribes to the wrong topic, so no messages are processed.

💡 Hint

Think about how the sleep affects message processing speed.

Sleeping inside the loop blocks the consumer from processing other messages, reducing scalability.

📝 Syntax

advanced

Which Kafka producer code snippet correctly sends messages asynchronously?

Choose the correct Kafka producer code that sends messages asynchronously and handles delivery reports.

A

from kafka import KafkaProducer
producer = KafkaProducer()
producer.send('topic', b'message').add_errback(lambda err: print('Error'))

B

from kafka import KafkaProducer
producer = KafkaProducer()
producer.send('topic', b'message').get()

C

from kafka import KafkaProducer
producer = KafkaProducer()
producer.send('topic', 'message')

D

from kafka import KafkaProducer
producer = KafkaProducer()
producer.send('topic', b'message').add_callback(lambda rec: print('Sent'))

💡 Hint

Look for correct usage of bytes and callback for async send.

Option D sends bytes and adds a callback for success, which is the correct async pattern.

🚀 Application

expert

How does event-driven architecture handle load spikes in Kafka?

In an event-driven Kafka system, how is a sudden spike in incoming events best handled to maintain scalability?

A By adding more consumer instances to process events in parallel and using Kafka partitions to distribute load.

B By slowing down producers to reduce event generation rate during spikes.

C By processing events synchronously in a single consumer to avoid race conditions.

D By storing all events in a single partition to ensure order and avoid duplication.

💡 Hint

Think about how Kafka partitions and consumers work together to scale.

Kafka partitions allow events to be split across consumers, so adding consumers helps handle spikes by parallel processing.