Bird
Raised Fist0
Microservicessystem_design~12 mins

Event-driven vs request-driven in Microservices - Architecture Patterns Compared

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
System Overview - Event-driven vs request-driven

This system compares two common microservice communication styles: event-driven and request-driven. It shows how services interact either by sending direct requests or by emitting and listening to events. Key requirements include decoupling services, ensuring scalability, and handling asynchronous or synchronous communication.

Architecture Diagram
          +-------------+                      +-------------+
          |  User/API   |                      |  User/API   |
          |  Request-   |                      |  Event-     |
          |  driven     |                      |  driven     |
          +------+------+
                 |                             
                 v                             
         +-------+-------+             +-------+-------+
         | Load Balancer |             | Load Balancer |
         +-------+-------+             +-------+-------+
                 |                             |
                 v                             v
         +-------+-------+             +-------+-------+
         | API Gateway   |             | API Gateway   |
         +-------+-------+             +-------+-------+
                 |                             |
                 v                             v
         +-------+-------+             +-------+-------+
         | Service A     |             | Service A     |
         +-------+-------+             +-------+-------+
                 |                             |
                 |                             +----------------+
                 |                                              |
                 v                                              v
         +-------+-------+                             +--------+--------+
         | Service B     |                             | Event Broker    |
         +-------+-------+                             +--------+--------+
                 |                                              |
                 v                                              v
         +-------+-------+                             +--------+--------+
         | Database      |                             | Service B       |
         +---------------+                             +----------------+
Components
User/API Request-driven
client
Initiates synchronous requests in request-driven style
User/API Event-driven
client
Initiates actions that trigger events in event-driven style
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway
API Gateway
api_gateway
Routes requests to appropriate services
Service A
service
Handles initial business logic and triggers downstream actions
Service B
service
Processes requests or events from Service A
Database
database
Stores persistent data for services
Event Broker
message_queue
Manages event publishing and subscription for asynchronous communication
Request Flow - 18 Hops
User/API Request-driven → Load Balancer
Load Balancer → API Gateway
API Gateway → Service A
Service A → Service B
Service B → Database
Database → Service B
Service B → Service A
Service A → API Gateway
API Gateway → Load Balancer
Load Balancer → User/API Request-driven
User/API Event-driven → Load Balancer
Load Balancer → API Gateway
API Gateway → Service A
Service A → Event Broker
Event Broker → Service B
Service B → Database
Database → Service B
Service B → Event Broker
Failure Scenario
Component Fails:Event Broker
Impact:Events cannot be delivered to subscribers, causing delays or loss of asynchronous processing
Mitigation:Use replicated brokers and persistent queues to ensure event durability and failover
Architecture Quiz - 3 Questions
Test your understanding
In the request-driven flow, which component directly calls Service B?
AService A
BAPI Gateway
CLoad Balancer
DDatabase
Design Principle
This architecture demonstrates the difference between synchronous request-driven communication, where services call each other directly and wait for responses, versus asynchronous event-driven communication, where services emit events to a broker and other services react independently. Event-driven design improves decoupling and scalability but requires reliable event delivery mechanisms.

Practice

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