Bird
Raised Fist0
Microservicessystem_design~25 mins

Event-driven vs request-driven in Microservices - Design Approaches 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
Design: Microservices Communication Model
Design communication patterns between microservices focusing on event-driven and request-driven approaches. Out of scope: detailed service business logic, UI design.
Functional Requirements
FR1: Enable communication between multiple microservices
FR2: Support asynchronous processing for some operations
FR3: Support synchronous request-response interactions for others
FR4: Ensure reliable message delivery and error handling
FR5: Allow scaling of services independently
FR6: Maintain data consistency across services
Non-Functional Requirements
NFR1: Handle up to 10,000 concurrent requests
NFR2: API response latency p99 under 300ms for synchronous calls
NFR3: Event processing latency p99 under 1 second
NFR4: Availability target 99.9% uptime
NFR5: Support eventual consistency for asynchronous flows
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
API Gateway or Service Mesh for request routing
Message Broker (e.g., Kafka, RabbitMQ) for events
Load Balancers
Service Registry and Discovery
Databases for state persistence
Monitoring and Logging tools
Design Patterns
Synchronous request-response pattern
Asynchronous event-driven pattern
Publish-subscribe messaging
Circuit breaker for fault tolerance
Event sourcing and CQRS
Reference Architecture
          +-------------------+          
          |   Client / UI     |          
          +---------+---------+          
                    |                    
          +---------v---------+          
          |   API Gateway     |          
          +---------+---------+          
                    |                    
    +---------------+---------------+  
    |                               |  
+---v---+                       +---v---+
|Service|                       |Service|
|  A    |                       |  B    |
+---+---+                       +---+---+
    |                               |    
    |  Request-driven (sync)         |    
    |------------------------------>|    
    |                               |    
    |                               |    
    | Event-driven (async)           |    
    |------------------------------>|    
    |                               |    
    |                               |    
    |       +----------------+      |    
    |       | Message Broker  |<-----+    
    |       +----------------+           
    |                               
    +-------------------------------+
Components
API Gateway
Nginx, Kong, or Envoy
Routes client requests to appropriate microservices, handles authentication and rate limiting
Microservices
Spring Boot, Node.js, or Go services
Implement business logic; communicate synchronously via HTTP or asynchronously via events
Message Broker
Apache Kafka or RabbitMQ
Facilitates asynchronous event-driven communication between services
Service Registry
Consul or Eureka
Keeps track of service instances for discovery and load balancing
Database
PostgreSQL or MongoDB
Stores persistent data for each microservice
Request Flow
1. Client sends a synchronous request to API Gateway.
2. API Gateway routes the request to the target microservice.
3. Microservice processes the request and returns a response immediately (request-driven).
4. For asynchronous operations, microservice publishes an event to the Message Broker.
5. Other microservices subscribe to relevant events and process them independently (event-driven).
6. Event processing results may update databases or trigger further events.
7. Clients can query microservices later to get updated state reflecting event processing.
Database Schema
Entities: ServiceA_Data, ServiceB_Data Relationships: Each service owns its data; eventual consistency maintained via events No direct cross-service foreign keys to keep services loosely coupled
Scaling Discussion
Bottlenecks
API Gateway becoming a single point of failure under high load
Message Broker throughput limits when event volume grows
Database write contention in high concurrency scenarios
Synchronous calls causing cascading delays if downstream services slow down
Solutions
Deploy multiple API Gateway instances behind a load balancer for high availability
Partition topics and scale Message Broker clusters horizontally
Use database sharding or separate databases per service to reduce contention
Implement circuit breakers and timeouts to isolate slow services and fallback gracefully
Interview Tips
Time: 10 minutes to clarify requirements and constraints, 20 minutes to design architecture and data flow, 10 minutes to discuss scaling and trade-offs, 5 minutes for questions
Explain difference between synchronous request-driven and asynchronous event-driven communication
Justify when to use each pattern based on latency and consistency needs
Describe components needed for reliable messaging and service discovery
Discuss how to handle failures and retries in both communication styles
Highlight scaling challenges and mitigation strategies

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