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

Scalability Analysis - Request-response vs event-driven

Growth Table: Request-response vs Event-driven

Users/Traffic	Request-response	Event-driven
100 users	Single server handles sync calls easily; low latency	Single event broker handles events; simple event queues
10K users	Need load balancers; DB connection pooling; some latency increase	Event broker scales with partitions; async processing smooths spikes
1M users	DB becomes bottleneck; sync calls cause timeouts; scaling app servers costly	Event brokers partitioned; microservices consume events independently; better throughput
100M users	Sync calls cause massive latency; DB sharding needed; complex retries	Multiple event brokers; event storage and replay; eventual consistency accepted

First Bottleneck

In request-response, the database and synchronous waiting cause the first bottleneck as user count grows. The system waits for replies, causing slowdowns and timeouts.

In event-driven, the event broker (message queue) can become the bottleneck if not partitioned or scaled, but async processing reduces direct load on DB and services.

Scaling Solutions

• Request-response: Use load balancers, increase app server instances horizontally, implement DB read replicas and sharding, use caching layers to reduce DB hits.
• Event-driven: Partition event brokers (Kafka partitions), scale consumers horizontally, use durable event storage, implement backpressure and retry mechanisms, adopt eventual consistency.

Back-of-Envelope Cost Analysis

Assuming 1M users generating 10 requests per second:

• Request-response: 10M QPS total; single DB handles ~10K QPS; need ~1000 DB replicas or sharding; app servers scale to thousands; network bandwidth high due to sync calls.
• Event-driven: 10M events/sec; Kafka cluster can handle ~1M events/sec per cluster; need ~10 clusters or partitions; consumers scale horizontally; network load spread over time.

Interview Tip

Start by explaining the difference: request-response is synchronous, event-driven is asynchronous. Discuss bottlenecks for each as traffic grows. Then propose scaling strategies matching those bottlenecks. Highlight trade-offs like latency vs throughput and consistency models.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and caching to reduce DB load, then consider sharding or moving to async/event-driven patterns to handle higher throughput.

Key Result

Request-response systems face DB and sync wait bottlenecks early; event-driven systems shift load to scalable event brokers and async consumers, enabling better throughput and resilience at large scale.

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