0
0
Microservicessystem_design~12 mins

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

Choose your learning style9 modes available
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-drivenLoad Balancer
Load BalancerAPI Gateway
API GatewayService A
Service AService B
Service BDatabase
DatabaseService B
Service BService A
Service AAPI Gateway
API GatewayLoad Balancer
Load BalancerUser/API Request-driven
User/API Event-drivenLoad Balancer
Load BalancerAPI Gateway
API GatewayService A
Service AEvent Broker
Event BrokerService B
Service BDatabase
DatabaseService B
Service BEvent 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.