FoundationsThe Design Interview Playbook
All courses

Request path for a simple API

Design the request path for a public HTTPS API that serves a read-heavy product page (HTML/JSON) to global users. Keep it simple — this lesson is about structure, not heroics.

  • Assume ~5k RPS peak reads
  • Mostly static / cacheable responses
  • One primary region for writes (admin updates)

Hint: Start with CDN → LB → app → DB; then add cache.

How strong candidates work

Great system-design answers are structured arguments, not component bingo. Use this loop every lesson:

  1. Clarify — functional + non-functional (QPS, latency, consistency, cost).
  2. APIs & data — what moves, who owns it, hot keys.
  3. Sketch — clients → edge → services → stores → async paths.
  4. Deep dive — bottleneck, failure, and what you would cut under time pressure.

Draw a clean request path for a cacheable product page. Label every box. Then hit Get AI critique and answer the follow-up.

  • Prefer named stores (Postgres, Redis, S3) over vague “DB”.
  • Say what is sync vs async.
  • Call out the first thing that breaks at 10× load.
Architecture canvasOpen full Diagram Studio ↗