Request-response vs event-driven in Microservices - Design Approaches Compared

Design: Microservices Communication System

Design focuses on communication patterns between microservices using request-response and event-driven approaches. It excludes internal service logic and database design beyond messaging needs.

Functional Requirements

FR1: Enable communication between multiple microservices

FR2: Support synchronous interactions where immediate response is needed

FR3: Support asynchronous interactions for decoupled processing

FR4: Ensure reliable message delivery between services

FR5: Handle failures gracefully without data loss

FR6: Allow scaling of services independently

Non-Functional Requirements

NFR1: System should handle up to 10,000 requests per second

NFR2: API response latency for synchronous calls should be under 200ms (p99)

NFR3: Event processing latency should be under 1 second

NFR4: System availability target is 99.9% uptime

NFR5: Services may be deployed across multiple data centers

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Load Balancer

Service Registry and Discovery

Message Broker (e.g., Kafka, RabbitMQ)

Synchronous HTTP/gRPC communication

Asynchronous event queues/topics

Retry and Dead Letter Queues

Monitoring and Logging tools

Design Patterns

Request-Response pattern for synchronous calls

Event-Driven Architecture for asynchronous communication

Publish-Subscribe pattern

Circuit Breaker for fault tolerance

Message Queuing for decoupling

Idempotency to handle retries

Reference Architecture

Client
  |
  | HTTP/gRPC Request
  v
API Gateway / Load Balancer
  |
  | Synchronous Request-Response
  v
Microservice A <-----> Microservice B
  |
  | Publishes Event
  v
Message Broker (Kafka/RabbitMQ)
  |
  | Asynchronous Event Delivery
  v
Microservice C, Microservice D (Subscribers)

Monitoring & Logging
Service Registry & Discovery

Components

API Gateway / Load Balancer

Nginx, Envoy, or AWS ALB

Routes client requests to appropriate microservices and balances load

Microservices

Any language/framework supporting HTTP/gRPC and messaging

Business logic units communicating synchronously or asynchronously

Message Broker

Apache Kafka or RabbitMQ

Handles asynchronous event delivery with durability and ordering guarantees

Service Registry & Discovery

Consul, Eureka, or Kubernetes DNS

Allows services to find each other dynamically

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Tracks system health, latency, errors, and message flows

Request Flow

1. Client sends synchronous request to Microservice A via API Gateway.

2. Microservice A processes request and calls Microservice B synchronously using HTTP/gRPC.

3. Microservice B responds immediately to Microservice A.

4. Microservice A returns response to client.

5. Separately, Microservice A publishes an event to the Message Broker asynchronously.

6. Message Broker delivers event to subscribed Microservices C and D.

7. Microservices C and D process events independently and acknowledge receipt.

8. If event processing fails, messages are retried or sent to Dead Letter Queue for manual inspection.

Database Schema

Not applicable as this design focuses on communication patterns. However, message broker stores events with metadata (event_id, timestamp, payload, status). Microservices maintain their own databases for business data.

Scaling Discussion

Bottlenecks

API Gateway can become a single point of failure or bottleneck under high load.

Synchronous calls can cause cascading failures if downstream services are slow or down.

Message Broker throughput limits event processing speed.

Service discovery delays can cause communication failures.

Monitoring systems may be overwhelmed with high volume logs and metrics.

Solutions

Use multiple API Gateway instances with load balancing and health checks.

Implement circuit breakers and timeouts to isolate failures in synchronous calls.

Partition topics and scale Message Broker clusters horizontally.

Use caching and local service registries to reduce discovery latency.

Aggregate and sample monitoring data to reduce overhead.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying synchronous vs asynchronous needs, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain difference between request-response (synchronous) and event-driven (asynchronous) communication.

Discuss when to use each pattern based on latency and coupling requirements.

Highlight components like API Gateway, Message Broker, and Service Discovery.

Describe failure handling with retries, circuit breakers, and dead letter queues.

Address scaling challenges and solutions for high throughput and availability.

Practice

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