Request-response vs event-driven in Microservices - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to show a request-response call between two microservices.

Microservices

response = serviceB.[1](request_data)

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

Asend_event

Bemit_signal

Cpublish_message

Dcall_api

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing event-driven terms like 'send_event' instead of direct call.

In request-response, one service calls another's API directly, so call_api fits.

2fill in blank

medium

Complete the code to publish an event in an event-driven microservice.

Microservices

event_bus.[1](event_data)

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

Arequest_response

Bpublish_event

Ccall_api

Dsend_request

Attempts:

3 left

💡 Hint

Common Mistakes

Using synchronous call terms like 'call_api' in event-driven context.

Event-driven systems use publish_event to send messages asynchronously.

3fill in blank

hard

Fix the error in the event-driven consumer code to properly handle incoming events.

Microservices

def on_event_received(event):
    [1](event.data)

# Missing function to process event data

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

Aemit_signal

Bcall_api

Cprocess_event

Dsend_event

Attempts:

3 left

💡 Hint

Common Mistakes

Using sending functions instead of processing functions.

The consumer should call a function like process_event to handle the event data.

4fill in blank

hard

Fill both blanks to complete the request-response flow: client sends request and waits for response.

Microservices

response = client.[1](request)
if response.[2] == 200:
    handle_success(response.data)

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

Asend_request

Bstatus_code

Cevent_type

Dpublish_event

Attempts:

3 left

💡 Hint

Common Mistakes

Using event-driven terms in request-response code.

Client sends a request with send_request and checks status_code for success.

5fill in blank

hard

Fill all three blanks to complete the event-driven consumer that subscribes, processes, and acknowledges events.

Microservices

event_bus.[1]('order_created', on_order)

def on_order(event):
    [2](event.data)
    event.[3]()

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

Asubscribe

Bprocess_order

Cacknowledge

Dpublish

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'publish' instead of 'subscribe' or 'acknowledge'.

The consumer subscribes to events, process_order handles data, and acknowledge confirms event processing.

Practice

1. Which communication pattern is best when a service needs an immediate answer from another service?

easy

A. Event-driven pattern

B. Request-response pattern

C. Batch processing

D. File transfer

Solution

1. Step 1: Understand request-response pattern

   This pattern involves one service sending a request and waiting for a direct reply from another service immediately.

2. Step 2: Compare with event-driven pattern

   Event-driven is asynchronous and does not guarantee immediate response, so it is not suitable for immediate answers.

3. Final Answer:

   Request-response pattern -> Option B

4. Quick Check:

   Immediate answer = Request-response [OK]

Hint: Immediate reply means request-response pattern [OK]

Common Mistakes:

• Confusing event-driven with immediate response
• Thinking batch processing is real-time
• Assuming file transfer is a communication pattern

2. Which of the following is the correct way to describe an event-driven system?

easy

A. Services emit events and other services react asynchronously.

B. Services send requests and wait for replies synchronously.

C. Services communicate only through shared databases.

D. Services batch process data at fixed intervals.

Solution

1. Step 1: Define event-driven communication

   In event-driven systems, services emit events without waiting for immediate replies, and other services react to these events asynchronously.

2. Step 2: Eliminate incorrect options

   Services send requests and wait for replies synchronously. describes request-response, C and D are unrelated to event-driven communication.

3. Final Answer:

   Services emit events and other services react asynchronously. -> Option A

4. Quick Check:

   Event-driven = asynchronous event emission [OK]

Hint: Event-driven means emit events, react later [OK]

Common Mistakes:

• Mixing synchronous request-response with event-driven
• Thinking event-driven requires waiting for replies
• Confusing batch processing with event-driven

3. Consider this scenario: Service A sends a request to Service B and waits for a response. Meanwhile, Service C emits an event that Service B listens to and processes asynchronously. Which pattern does Service A use with Service B, and which pattern does Service C use with Service B?

medium

A. Service A uses request-response; Service C uses event-driven

B. Both use event-driven

C. Both use request-response

D. Service A uses event-driven; Service C uses request-response

Solution

1. Step 1: Identify Service A and B interaction

   Service A sends a request and waits for a response from Service B, which is the request-response pattern.

2. Step 2: Identify Service C and B interaction

   Service C emits an event that Service B processes asynchronously, which is event-driven communication.

3. Final Answer:

   Service A uses request-response; Service C uses event-driven -> Option A

4. Quick Check:

   Request-response = direct wait; Event-driven = async event [OK]

Hint: Request-response waits; event-driven emits and forgets [OK]

Common Mistakes:

• Swapping patterns between services
• Assuming all communication is synchronous
• Ignoring asynchronous event processing

4. A developer implemented a microservice system where Service X sends an event and immediately expects a response from Service Y. What is the main issue with this design?

medium

A. Events must be stored in a database before processing.

B. Request-response pattern is not suitable for microservices.

C. Services should never communicate directly.

D. Event-driven systems do not support immediate responses; this breaks the pattern.

Solution

1. Step 1: Understand event-driven communication

   Event-driven systems are asynchronous; services emit events without waiting for immediate replies.

2. Step 2: Identify the design issue

   Expecting an immediate response after sending an event contradicts the asynchronous nature of event-driven systems, causing design problems.

3. Final Answer:

   Event-driven systems do not support immediate responses; this breaks the pattern. -> Option D

4. Quick Check:

   Event-driven ≠ immediate response [OK]

Hint: Events don't get immediate replies in event-driven [OK]

Common Mistakes:

• Thinking request-response is bad for microservices
• Believing services must never communicate directly
• Confusing event storage with communication pattern

5. You are designing a large e-commerce system. For order placement, the user must get immediate confirmation. For inventory updates and shipping notifications, delays are acceptable. Which combination of communication patterns should you use?

hard

A. Use event-driven for order confirmation; request-response for inventory and shipping

B. Use request-response for all communications

C. Use request-response for order confirmation; event-driven for inventory and shipping

D. Use event-driven for all communications

Solution

1. Step 1: Analyze order confirmation requirement

   User needs immediate confirmation, so request-response pattern fits best for order placement.

2. Step 2: Analyze inventory and shipping updates

   These can be delayed and processed asynchronously, so event-driven pattern suits these tasks.

3. Step 3: Combine patterns appropriately

   Use request-response for immediate feedback and event-driven for asynchronous updates to scale well and keep user experience smooth.

4. Final Answer:

   Use request-response for order confirmation; event-driven for inventory and shipping -> Option C

5. Quick Check:

   Immediate = request-response; delayed = event-driven [OK]

Hint: Immediate needs request-response; delays use event-driven [OK]

Common Mistakes:

• Using event-driven for immediate confirmation
• Using request-response for all async tasks
• Ignoring user experience needs