Event-driven vs request-driven in Microservices - Design Approaches Compared

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