How would you handle around 1 million requests hitting your system in 15 minutes?

What the interviewer wants to learn

  • Your ability to think at scale and break down a large traffic spike into manageable components.
  • Understanding of load balancing, caching, queuing, autoscaling, and data‑store bottlenecks.
  • How you prioritize reliability, latency, and cost while keeping the design simple.

How to structure your answer

1. **Clarify requirements** – ask about latency goals, read‑vs‑write mix, durability, and acceptable failure modes.

2. **Estimate load** – translate 1 M requests / 15 min into RPS and peak concurrency.

3. **Layered architecture** – outline front‑end, service, and data layers, and where each scaling technique fits.

4. **Scaling mechanisms** – describe load balancers, horizontal scaling, caching, async processing, and autoscaling triggers.

5. **Resilience & monitoring** – mention health checks, circuit breakers, rate limiting, and observability.

6. **Trade‑offs** – briefly note cost, complexity, and eventual consistency considerations.

Example answer

“First I’d confirm the SLAs – let’s say we need sub‑second response for reads and can tolerate a few seconds for background writes. One million requests in 15 minutes is roughly 1,111 RPS, with peaks perhaps 2 × that. I’d start with a stateless front‑end tier behind a DNS‑based load balancer that distributes traffic to a pool of web servers behind an L4 load balancer. Those servers would cache hot data in an in‑memory store like Redis to shave latency and reduce DB hits. For write‑heavy paths I’d enqueue work in a message queue (e.g., Kafka) and process it with a pool of worker services that can autoscale based on queue depth. The database would be sharded or use read replicas to handle the read load, and I’d enable auto‑scaling groups that add or remove instances based on CPU and request latency metrics. Finally, I’d add rate limiting at the edge, health checks, circuit breakers, and full monitoring so we can react quickly if any component becomes a bottleneck.”

Mistakes to avoid

  • Jumping straight into a diagram without first clarifying latency, durability, or budget constraints.
  • Assuming a single solution (e.g., just adding more servers) without addressing caching, queuing, or database limits.
  • Ignoring failure scenarios; not mentioning health checks, graceful degradation, or circuit breakers.
  • Over‑complicating the design with unnecessary micro‑services or exotic technologies for a relatively simple load.
  • Forgetting to discuss observability and how you’d know the system is performing as expected.

More system design questions