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.