What is the best way to practice mock system design interviews?

The best way to practice mock system design interviews is to use a structured platform like System Design Lab. It provides real interview questions (design URL shortener, design Twitter, design Netflix), an interactive diagram builder, an AI interviewer that asks follow-up questions, and detailed feedback on your architecture, scalability decisions, and trade-offs — exactly like a real FAANG interview.

How do I prepare for a system design interview?

To prepare for a system design interview: (1) Learn core concepts like distributed systems, caching, databases, sharding, and message queues. (2) Practice drawing architecture diagrams under time pressure. (3) Take knowledge quizzes to test your understanding. (4) Do mock system design interviews with AI feedback to get comfortable explaining your decisions. (5) Review community solutions to see how others approach the same problems. System Design Lab covers all five steps in one platform.

What system design interview questions should I practice?

Common system design interview questions include: Design a URL shortener, Design Twitter/social media feed, Design Netflix/video streaming, Design a distributed cache, Design a rate limiter, Design a notification system, Design a ride-sharing app like Uber. System Design Lab offers a growing bank of real interview problems — Twitter, YouTube, URL shortener, Uber and more — covering the major categories asked at FAANG and top-tier tech companies.

Is there a free mock system design interview tool?

Yes — System Design Lab offers a free 7-day trial with access to 3 mock system design interview problems, all learning modules, all quizzes, and community solutions. No credit card required. Premium (₹999 for 90 days) unlocks unlimited problems and AI interviewer access.

How does System Design Lab's AI interview feedback work?

After you submit your system design, the AI evaluates your written explanation and architecture diagram together. It scores you on completeness, scalability, fault tolerance, and clarity, then gives you specific, actionable feedback — similar to what a senior engineer would say after your interview. You can also chat with an AI interviewer in real-time during your attempt.

System Design Lab›System Design Questions›Design API Gateway

Design API Gateway

MediumInfrastructurerate-limitingsecurityroutingdistributed

Question Overview

Design the single front door for a company's microservices, handling routing, authentication, rate limiting, and transformations. The challenge is doing all of it at a million requests per second while adding only a few milliseconds and never becoming a single point of failure.…

Requirements

Route by host, path, method, and headers to 500 upstream services, with weighted canary splits
Terminate TLS, authenticate API keys, OAuth tokens, and JWTs, and enforce per-route scopes
Per-key and per-route rate limiting, plus request and response transformation
Timeouts, retries, and circuit breaking toward upstreams; logs, metrics, and traces for every request
Under 5 ms p99 added latency and 99.99% availability with no single point of failure
Config changes live on every node within 10 s, without restarts or dropped connections

Back-of-the-envelope numbers

Traffic: 1M RPS peak ÷ 3 regions ≈ 333K RPS per region; assuming 3:1 peak-to-average, ≈ 333K RPS average ≈ 29B requests/day
Bandwidth: 1M RPS × (2 KB request + 10 KB response) = 12 GB/s ≈ 96 Gbps through the fleet at peak
Fleet: assuming ~20K RPS per 16-core node with TLS and plugins, 1M ÷ 20K = 50 nodes, ~100 with zone redundancy and 2× headroom
API key cache: 2M keys × ~200 B (hash, tenant, scopes, limits) ≈ 400 MB, replicated in every node's memory
Rate limiting: a central counter per request means 1M Redis ops/s at peak (~10 shards at 100K ops/s); local buckets synced every ~100 ms cut this sharply
Access logs: 333K RPS average × 500 B ≈ 167 MB/s ≈ 14.4 TB/day, shipped asynchronously through Kafka
Config: 5,000 routes × ~2 KB ≈ 10 MB snapshot, cheap to push in full to every node and swap atomically

Key components

Data plane: stateless proxy nodes (Envoy- or NGINX-based) behind L4 load balancers in each region, scaled horizontally
Request pipeline: TLS termination, route match, authentication, authorization, rate limit, transform, upstream call, response transform, then logging
Route matching: routes compiled into a per-host radix tree so lookup cost depends on path length, not route count
Control plane: admin API writes versioned config to etcd or a database and streams snapshots to nodes xDS-style; nodes keep the last good config
Auth: JWTs verified locally with cached JWKS public keys; API keys resolved from an in-memory cache fed by the auth service with revocation events
Rate limiter: token buckets kept locally and synced to Redis every ~100 ms for approximate global limits, failing open if Redis is down
Upstream resilience: per-service connection pools, timeouts, retry budgets, outlier detection, and circuit breakers

Common mistakes

Calling the auth service and Redis synchronously on every request, adding round trips and turning both into critical dependencies
Keeping session or request state on gateway nodes, so they cannot be freely added, drained, or replaced
Putting business logic and response aggregation into the gateway, creating a monolith bottleneck owned by one team
Automatically retrying non-idempotent POSTs, or retrying without a budget so retries amplify an upstream overload
Pushing config to all nodes at once without validation or staged rollout, so one bad route breaks every API
Making the rate limiter fail closed, so a Redis outage rejects all traffic instead of briefly over-admitting

Likely follow-ups

How would you roll out a config change so a bad route cannot take down all traffic?
How would you enforce a global limit of 1,000 requests/s for one API key across 3 regions?
How would you revoke a compromised API key or JWT within seconds?
How would you proxy WebSockets and other long-lived streaming connections?
How would you isolate a tenant whose traffic spike threatens everyone else?
When would you split into several gateways, such as backend-for-frontend, instead of one?

No community solutions yet

Be the first to publish your solution

Practice ‘Design API Gateway’ with an AI Interviewer

Get scored feedback on your diagram, scalability approach, and trade-offs. Free while we grow — up to 3 full interviews a day.

Try a 5-minute drill — no signup