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

Scalability Analysis - Event-driven vs request-driven

Growth Table: Event-driven vs Request-driven at Different Scales

Scale	Request-driven	Event-driven
100 users	Simple synchronous calls; low latency; easy debugging	Basic event queues; low message volume; simple event handlers
10,000 users	Increased API calls; higher latency; need load balancers; some retries	Growing event queues; need message brokers; asynchronous processing helps throughput
1,000,000 users	API servers saturate CPU; DB connection limits hit; latency spikes; retries increase	Message brokers become bottleneck; event ordering and duplication issues; need partitioning and scaling consumers
100,000,000 users	Multiple API clusters; global load balancing; DB sharding; caching layers essential	Distributed event brokers; multi-region replication; complex event routing; eventual consistency challenges

First Bottleneck

For request-driven systems, the first bottleneck is usually the synchronous API servers and database connections because each request waits for a response, causing CPU and DB connection saturation as users grow.

For event-driven systems, the bottleneck often appears at the message broker or event queue, which must handle high throughput and maintain message order and durability.

Scaling Solutions

• Request-driven: Use horizontal scaling of API servers behind load balancers, implement caching layers to reduce DB load, use connection pooling, and shard databases to distribute load.
• Event-driven: Scale message brokers horizontally (partition topics/queues), use multiple consumer groups for parallel processing, implement idempotent event handlers, and use dead-letter queues for failures.
• Both approaches benefit from CDN for static content and edge caching to reduce backend load.

Back-of-Envelope Cost Analysis

Assuming 1 million users generating 1 request or event per second:

• Request-driven: 1 million QPS is beyond a single DB instance (max ~10K QPS). Need ~100 DB replicas or sharding. API servers need ~200-500 instances (assuming 2000-5000 concurrent connections each).
• Event-driven: Message broker must handle 1 million messages/sec. Kafka cluster with multiple brokers can handle ~100K-200K messages/sec per broker, so need 5-10 brokers. Consumers scaled horizontally to process events timely.
• Network bandwidth: 1 million requests/events with 1KB payload = ~1GB/s (~8Gbps), requiring high network capacity and efficient compression.

Interview Tip

Start by clarifying the system's workload and latency needs. Discuss how synchronous request-driven systems handle user interactions directly, while event-driven systems decouple components for better scalability. Identify bottlenecks at each scale and propose targeted solutions like load balancing, caching, sharding, or message broker scaling. Use real numbers to justify your approach.

Self Check

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

Answer: Introduce read replicas and caching to reduce direct DB load. If writes increase, consider sharding or partitioning the database. Also, optimize queries and use connection pooling to handle more connections efficiently.

Key Result

Request-driven systems first hit API server and DB connection limits as users grow, requiring horizontal scaling and caching. Event-driven systems first bottleneck at message brokers, needing broker clustering and consumer scaling for high throughput.

Practice

1. Which statement best describes an event-driven microservice architecture?

easy

A. Services communicate by sending messages without waiting for immediate responses.

B. Services make direct calls and wait for responses before continuing.

C. Services share a common database to exchange data synchronously.

D. Services use batch processing to handle requests at fixed intervals.

Solution

1. Step 1: Understand event-driven communication

   Event-driven systems use messages or events to notify other services asynchronously, without waiting for a reply.

2. Step 2: Compare with request-driven communication

   Request-driven systems make direct calls and wait for responses, which is synchronous communication.

3. Final Answer:

   Services communicate by sending messages without waiting for immediate responses. -> Option A

4. Quick Check:

   Event-driven = asynchronous messaging [OK]

Hint: Event-driven means no waiting for replies, just messages [OK]

Common Mistakes:

• Confusing event-driven with synchronous calls
• Thinking event-driven requires shared databases
• Assuming event-driven always uses batch processing

2. Which of the following is the correct way to describe a request-driven call in microservices?

easy

A. Service A sends an event and continues without waiting.

B. Service A writes data to a shared database for Service B to read later.

C. Service A processes requests in batches asynchronously.

D. Service A calls Service B and waits for a response before proceeding.

Solution

1. Step 1: Identify request-driven behavior

   Request-driven means a service calls another and waits for the response before moving on.

2. Step 2: Eliminate other options

   Options A and D describe asynchronous or event-driven behavior; Service A writes data to a shared database for Service B to read later. describes shared database, not direct calls.

3. Final Answer:

   Service A calls Service B and waits for a response before proceeding. -> Option D

4. Quick Check:

   Request-driven = synchronous call and wait [OK]

Hint: Request-driven means wait for reply before continuing [OK]

Common Mistakes:

• Mixing event-driven with request-driven
• Thinking shared database equals request-driven
• Confusing batch processing with request-driven calls

3. Consider this scenario: Service A sends an event to a message broker, and Service B listens and processes it asynchronously. What is the main advantage of this design?

medium

A. Service B can process events at its own pace without blocking Service A.

B. Service B must respond immediately to Service A's request.

C. Service A and B share the same database for faster communication.

D. Service A waits for Service B to finish processing before continuing.

Solution

1. Step 1: Analyze asynchronous event processing

   Service A sends an event and does not wait; Service B processes independently.

2. Step 2: Identify the advantage

   This allows Service B to handle events at its own speed without blocking Service A, improving scalability and decoupling.

3. Final Answer:

   Service B can process events at its own pace without blocking Service A. -> Option A

4. Quick Check:

   Asynchronous event-driven = decoupled processing [OK]

Hint: Async events let receivers work independently [OK]

Common Mistakes:

• Assuming sender waits for receiver
• Confusing shared database with event broker
• Expecting immediate response in event-driven

4. You have a microservice that calls another service synchronously but experiences high latency and failures. Which change can improve reliability using event-driven design?

medium

A. Increase the timeout for synchronous calls to wait longer.

B. Replace synchronous calls with asynchronous events and retries.

C. Use a shared database for both services to read and write data.

D. Batch multiple synchronous calls into one to reduce overhead.

Solution

1. Step 1: Identify problem with synchronous calls

   High latency and failures occur because the caller waits and depends on the callee's immediate response.

2. Step 2: Apply event-driven solution

   Switching to asynchronous events decouples services, allowing retries and better fault tolerance without blocking.

3. Final Answer:

   Replace synchronous calls with asynchronous events and retries. -> Option B

4. Quick Check:

   Event-driven improves reliability by decoupling [OK]

Hint: Async events with retries reduce blocking and failures [OK]

Common Mistakes:

• Just increasing timeout doesn't fix failures
• Shared database doesn't solve latency issues
• Batching synchronous calls still blocks

5. A company wants to design a microservices system for online orders. They need fast user feedback and flexible processing of orders. Which architecture best fits their needs?

hard

A. Use only request-driven calls for all services to ensure immediate responses.

B. Use only event-driven design for all services to maximize decoupling.

C. Use request-driven calls for order validation and event-driven for inventory updates.

D. Use batch processing to handle orders every hour for efficiency.

Solution

1. Step 1: Analyze requirements for fast feedback and flexibility

   Fast user feedback needs synchronous validation; flexible processing benefits from asynchronous events.

2. Step 2: Combine architectures appropriately

   Request-driven calls provide immediate validation; event-driven updates allow inventory to process independently and scale.

3. Final Answer:

   Use request-driven calls for order validation and event-driven for inventory updates. -> Option C

4. Quick Check:

   Mix sync for speed + async for flexibility [OK]

Hint: Mix sync for fast feedback, async for flexible tasks [OK]

Common Mistakes:

• Using only event-driven delays user feedback
• Using only request-driven limits scalability
• Batch processing is too slow for online orders