1. Use‑case and requirement clarification
In any system design interview, your first job is to understand what problem you’re actually solving before you draw boxes.
What you clarify first
You want to clarify three things:
-
Actors (users / systems)
Who uses this system? Humans, internal services, external APIs? -
Core flows (happy paths)
What are the main actions they take, end to end? -
Success criteria
How do we know this design is “good enough”? What’s the key goal: low latency, simplicity, cost, reliability?
Example: “Design Instagram feed”
Start by asking clarifying questions, including at least one about users, scale, and latency.
About users / product:
- Who are the primary users of the feed?
- Just normal users, or also businesses, influencers, advertisers?
- What should appear in the feed?
- Only people the user follows? Ads? Recommended posts?
About scale:
- Roughly how many monthly active users and daily active users should we design for?
- What’s the expected peak QPS (requests per second) for loading a feed?
About latency (and other quality expectations):
- What’s an acceptable p95 latency to load the feed for a user?
- For example: should most users see their feed within 300 ms? 1 second?
- How fresh should the feed be?
- Can posts be a few seconds behind, or must they be real‑time?
Other helpful clarifiers:
- Do we need to support infinite scroll?
- Do we need offline support or just online?
- What is MVP vs. stretch features (e.g., stories, reels, comments are out of scope)?
You don’t need perfect numbers; you need enough to choose between options like:
- Single database vs sharded cluster
- Cache or no cache
- Push vs pull model for feed generation
In an interview, ask 3–7 sharp questions, then propose your own assumptions out loud (“If actual numbers differ, architecture can be adjusted like X or Y.”).