Request-response vs event-driven in Microservices - Architecture Patterns Compared

System Overview - Request-response vs event-driven

This system compares two common communication styles in microservices: request-response and event-driven. Request-response is a direct, synchronous way where one service asks another and waits for a reply. Event-driven is asynchronous, where services emit events and others react without waiting.

Key requirements include clear communication, scalability, and fault tolerance.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +---------------------+---------------------+
  |                     |                     |
Request-Response     Event-Driven          Event Bus
Service A            Service B             (Message Queue)
  |                     |                     |
Database A           Database B            Service C
  |                     |                     |
Cache A              Cache B               Database C

Components

User

client

Initiates requests to the system

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Routes requests to appropriate services and handles authentication

Request-Response Service A

service

Handles synchronous requests and responses

Database A

database

Stores data for Service A

Cache A

cache

Speeds up data retrieval for Service A

Event-Driven Service B

service

Emits events asynchronously for other services to consume

Event Bus (Message Queue)

message_queue

Decouples services by delivering events asynchronously

Service C

service

Consumes events from the event bus and processes them

Database B

database

Stores data for Service B

Cache B

cache

Speeds up data retrieval for Service B

Database C

database

Stores data for Service C

Request Flow - 9 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Request-Response Service A

Request-Response Service A → Cache A

Cache A → Request-Response Service A

Request-Response Service A → User

Event-Driven Service B → Event Bus (Message Queue)

Event Bus (Message Queue) → Service C

Service C → Database C

Failure Scenario

Component Fails:Event Bus (Message Queue)

Impact:Events cannot be delivered to consuming services, causing delays or loss of asynchronous processing.

Mitigation:Use message queue replication and persistence to avoid data loss and enable failover. Services can retry sending events.

Architecture Quiz - 3 Questions

Which component handles synchronous communication in this architecture?

A Service C

B Event Bus (Message Queue)

C Request-Response Service A

D Cache B

Design Principle

This architecture shows how request-response enables immediate, synchronous communication suitable for direct user interactions, while event-driven design allows services to communicate asynchronously, improving scalability and decoupling. Both styles have distinct components and failure modes, requiring different handling strategies.

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