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

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding communication styles in microservices

Which statement best describes the main difference between request-response and event-driven communication in microservices?

A Both request-response and event-driven are synchronous communication styles.

B Request-response is asynchronous and does not wait for a reply; event-driven is synchronous and waits for a reply.

C Both request-response and event-driven require the sender to wait for a reply before continuing.

D Request-response is synchronous and waits for a reply; event-driven is asynchronous and does not wait for a reply.

💡 Hint

Think about whether the sender waits for a response or not.

Request-response communication is synchronous, meaning the sender waits for the receiver to respond before continuing. Event-driven communication is asynchronous; the sender emits an event and continues without waiting for a reply.

❓ Architecture

intermediate

Choosing communication style for a user login service

You are designing a user login microservice that must verify credentials and immediately respond with success or failure. Which communication style is most appropriate?

A Request-response, because the client needs an immediate answer to proceed.

B Event-driven, because it allows the login service to process requests asynchronously.

C Event-driven, because it reduces the need for direct communication between services.

D Request-response, because it queues login requests for later processing.

💡 Hint

Consider if the client needs an immediate answer or can wait.

Login requires immediate feedback to the user, so request-response is suitable because it provides synchronous communication with immediate results.

❓ scaling

advanced

Scaling microservices with event-driven architecture

Which advantage does event-driven architecture provide when scaling microservices compared to request-response?

A It allows services to process events independently and at their own pace, improving scalability.

B It forces services to wait for responses, reducing load on downstream services.

C It requires synchronous calls, which simplifies scaling by limiting concurrency.

D It eliminates the need for message brokers, reducing infrastructure complexity.

💡 Hint

Think about how asynchronous processing affects load handling.

Event-driven architecture decouples services, allowing them to handle events asynchronously and independently, which improves scalability and fault tolerance.

❓ tradeoff

advanced

Tradeoffs between request-response and event-driven communication

What is a common tradeoff when choosing event-driven communication over request-response in microservices?

A Request-response communication is always slower than event-driven communication.

B Event-driven communication guarantees immediate consistency and simpler error handling.

C Event-driven communication can increase complexity due to eventual consistency and harder debugging.

D Request-response communication eliminates the need for message brokers.

💡 Hint

Consider the challenges of asynchronous systems.

Event-driven systems often face challenges like eventual consistency, increased complexity, and difficulty tracing errors compared to synchronous request-response systems.

❓ estimation

expert

Estimating message volume in event-driven microservices

A microservice emits an event for every user action. If there are 10,000 users each performing 5 actions per minute, how many events per second does the system generate?

A Approximately 500 events per second

B Approximately 833 events per second

C Approximately 3,000 events per second

D Approximately 50,000 events per second

💡 Hint

Calculate total events per minute, then convert to per second.

Total events per minute = 10,000 users * 5 actions = 50,000 events/minute. Divide by 60 seconds to get approximately 833 events/second.

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