Event-driven vs request-driven in Microservices - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify the type of communication where a service sends a message and continues without waiting.

Microservices

if communication_type == '[1]':
    print("Service sends event and moves on")

Drag options to blanks, or click blank then click option'

Aevent-driven

Brequest-driven

Csynchronous

Dblocking

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing event-driven with request-driven communication

Thinking synchronous means no waiting

In event-driven communication, the service sends an event and continues without waiting for a response.

2fill in blank

medium

Complete the code to describe the communication style where a service waits for a response after sending a request.

Microservices

if communication_type == '[1]':
    print("Service sends request and waits for reply")

Drag options to blanks, or click blank then click option'

Aasynchronous

Bevent-driven

Cfire-and-forget

Drequest-driven

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up asynchronous event-driven with synchronous request-driven

Assuming event-driven always waits for a response

Request-driven communication involves sending a request and waiting for a response, typically synchronous.

3fill in blank

hard

Fix the error in the code that wrongly treats event-driven communication as synchronous.

Microservices

def send_message():
    response = send_event()  # [1] call
    print("Continue processing")

Drag options to blanks, or click blank then click option'

Ablocking

Basynchronous

Csynchronous

Ddirect

Attempts:

3 left

💡 Hint

Common Mistakes

Using synchronous or blocking calls for event-driven communication

Assuming all calls wait for a response

Event-driven communication is asynchronous, so the call should be asynchronous, not synchronous.

4fill in blank

hard

Fill both blanks to complete the description of event-driven and request-driven communication.

Microservices

Event-driven communication is [1], while request-driven communication is [2].

Drag options to blanks, or click blank then click option'

Aasynchronous

Bsynchronous

Cblocking

Dfire-and-forget

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping asynchronous and synchronous terms

Confusing blocking with asynchronous

Event-driven is asynchronous (non-blocking), request-driven is synchronous (blocking).

5fill in blank

hard

Fill all three blanks to complete the code that models a microservice handling both communication styles.

Microservices

def handle_communication(type):
    if type == '[1]':
        send_event()  # [2] call
    elif type == '[3]':
        send_request()  # waits for response

Drag options to blanks, or click blank then click option'

Aevent-driven

Basynchronous

Crequest-driven

Dsynchronous

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up event-driven and request-driven labels

Using synchronous for event-driven calls

Event-driven uses asynchronous calls; request-driven uses synchronous calls.

Practice

1. Which statement best describes an event-driven microservice architecture?

easy

A. Services communicate by sending messages without waiting for immediate responses.

B. Services make direct calls and wait for responses before continuing.

C. Services share a common database to exchange data synchronously.

D. Services use batch processing to handle requests at fixed intervals.

Solution

1. Step 1: Understand event-driven communication

   Event-driven systems use messages or events to notify other services asynchronously, without waiting for a reply.

2. Step 2: Compare with request-driven communication

   Request-driven systems make direct calls and wait for responses, which is synchronous communication.

3. Final Answer:

   Services communicate by sending messages without waiting for immediate responses. -> Option A

4. Quick Check:

   Event-driven = asynchronous messaging [OK]

Hint: Event-driven means no waiting for replies, just messages [OK]

Common Mistakes:

• Confusing event-driven with synchronous calls
• Thinking event-driven requires shared databases
• Assuming event-driven always uses batch processing

2. Which of the following is the correct way to describe a request-driven call in microservices?

easy

A. Service A sends an event and continues without waiting.

B. Service A writes data to a shared database for Service B to read later.

C. Service A processes requests in batches asynchronously.

D. Service A calls Service B and waits for a response before proceeding.

Solution

1. Step 1: Identify request-driven behavior

   Request-driven means a service calls another and waits for the response before moving on.

2. Step 2: Eliminate other options

   Options A and D describe asynchronous or event-driven behavior; Service A writes data to a shared database for Service B to read later. describes shared database, not direct calls.

3. Final Answer:

   Service A calls Service B and waits for a response before proceeding. -> Option D

4. Quick Check:

   Request-driven = synchronous call and wait [OK]

Hint: Request-driven means wait for reply before continuing [OK]

Common Mistakes:

• Mixing event-driven with request-driven
• Thinking shared database equals request-driven
• Confusing batch processing with request-driven calls

3. Consider this scenario: Service A sends an event to a message broker, and Service B listens and processes it asynchronously. What is the main advantage of this design?

medium

A. Service B can process events at its own pace without blocking Service A.

B. Service B must respond immediately to Service A's request.

C. Service A and B share the same database for faster communication.

D. Service A waits for Service B to finish processing before continuing.

Solution

1. Step 1: Analyze asynchronous event processing

   Service A sends an event and does not wait; Service B processes independently.

2. Step 2: Identify the advantage

   This allows Service B to handle events at its own speed without blocking Service A, improving scalability and decoupling.

3. Final Answer:

   Service B can process events at its own pace without blocking Service A. -> Option A

4. Quick Check:

   Asynchronous event-driven = decoupled processing [OK]

Hint: Async events let receivers work independently [OK]

Common Mistakes:

• Assuming sender waits for receiver
• Confusing shared database with event broker
• Expecting immediate response in event-driven

4. You have a microservice that calls another service synchronously but experiences high latency and failures. Which change can improve reliability using event-driven design?

medium

A. Increase the timeout for synchronous calls to wait longer.

B. Replace synchronous calls with asynchronous events and retries.

C. Use a shared database for both services to read and write data.

D. Batch multiple synchronous calls into one to reduce overhead.

Solution

1. Step 1: Identify problem with synchronous calls

   High latency and failures occur because the caller waits and depends on the callee's immediate response.

2. Step 2: Apply event-driven solution

   Switching to asynchronous events decouples services, allowing retries and better fault tolerance without blocking.

3. Final Answer:

   Replace synchronous calls with asynchronous events and retries. -> Option B

4. Quick Check:

   Event-driven improves reliability by decoupling [OK]

Hint: Async events with retries reduce blocking and failures [OK]

Common Mistakes:

• Just increasing timeout doesn't fix failures
• Shared database doesn't solve latency issues
• Batching synchronous calls still blocks

5. A company wants to design a microservices system for online orders. They need fast user feedback and flexible processing of orders. Which architecture best fits their needs?

hard

A. Use only request-driven calls for all services to ensure immediate responses.

B. Use only event-driven design for all services to maximize decoupling.

C. Use request-driven calls for order validation and event-driven for inventory updates.

D. Use batch processing to handle orders every hour for efficiency.

Solution

1. Step 1: Analyze requirements for fast feedback and flexibility

   Fast user feedback needs synchronous validation; flexible processing benefits from asynchronous events.

2. Step 2: Combine architectures appropriately

   Request-driven calls provide immediate validation; event-driven updates allow inventory to process independently and scale.

3. Final Answer:

   Use request-driven calls for order validation and event-driven for inventory updates. -> Option C

4. Quick Check:

   Mix sync for speed + async for flexibility [OK]

Hint: Mix sync for fast feedback, async for flexible tasks [OK]

Common Mistakes:

• Using only event-driven delays user feedback
• Using only request-driven limits scalability
• Batch processing is too slow for online orders