Bird
Raised Fist0
Microservicessystem_design~5 mins

Request-response vs event-driven in Microservices - Quick Revision & Key Differences

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is the main characteristic of the request-response communication pattern?
In request-response, a service sends a request and waits for a direct reply from another service before continuing.
Click to reveal answer
beginner
How does event-driven communication differ from request-response?
Event-driven communication uses events to notify other services asynchronously, without waiting for an immediate reply.
Click to reveal answer
beginner
Give a real-life example of request-response communication.
Ordering food at a restaurant: you place an order (request) and wait for the waiter to bring your food (response).
Click to reveal answer
beginner
Give a real-life example of event-driven communication.
Fire alarm system: when smoke is detected, the alarm (event) sounds and multiple systems respond independently without waiting.
Click to reveal answer
intermediate
What is a key advantage of event-driven systems over request-response in microservices?
Event-driven systems improve scalability and decoupling because services do not wait for replies and can process events independently.
Click to reveal answer
Which communication pattern involves waiting for a direct reply before proceeding?
AEvent-driven
BMulticast
CBroadcast
DRequest-response
In event-driven architecture, how do services communicate?
AAsynchronously through events
BSynchronously with immediate replies
COnly through direct API calls
DUsing shared databases
Which pattern is better for decoupling services in microservices?
AEvent-driven
BMonolithic
CRequest-response
DSynchronous polling
What is a downside of request-response communication?
AServices do not get immediate feedback
BIt can cause tight coupling and waiting delays
CIt is always asynchronous
DIt requires event brokers
Which scenario fits event-driven communication best?
AClient requests data and waits for response
BUser logs in and waits for confirmation
CSensor sends data to multiple systems when triggered
DSynchronous database query
Explain the differences between request-response and event-driven communication in microservices.
Think about how services wait or don't wait for answers.
You got /5 concepts.
    Describe a real-life example for each communication pattern and how it relates to microservices.
    Use everyday situations to explain technical ideas.
    You got /4 concepts.

      Practice

      (1/5)
      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