Skip to main content
Before we dive into solving system design problems, one honest note: if you are new to system design, the first problems you tackle will introduce many unfamiliar concepts. Feeling like you don’t know anything at first is normal. The reliable way to get better is deliberate practice: solve a variety of problems until recurring patterns become obvious. In interviews you are not expected to build a perfect, multi-region production system in 45 minutes. Instead, interviewers evaluate how you approach the problem. When interviewers write feedback they rarely call out knowledge of a particular tool. They typically evaluate how you structured your solution and how you communicated it. Positive feedback often references the candidate’s approach:
  • The candidate turned an ambiguous prompt into a clear, testable problem.
  • The candidate explained trade-offs and why they chose one option over another.
  • The candidate adapted to hints from the interviewer and iterated on the design.
Two frequent negative patterns are worth calling out explicitly:
  • Rushing straight into architecture without clarifying requirements or asking questions.
  • Over-engineering: adding unnecessary caches, shards, queues, or multi-region complexity that makes the design too big to finish within the interview time.
Avoid jumping to the architecture or over-engineering. Use early clarifying questions and scope-limiting assumptions to produce a clear, focused design you can present in the time allowed.
An infographic titled "What Interviewers Actually Expect" showing two panels: a simple system diagram on the left labeled "Straight Into Architecture" with servers, a database, cache and a load balancer, and a right panel labeled "Over-Engineers" with icons for caches, shards and queues.
If I distill what interviewers are evaluating, it boils down to four core competencies:
  1. Judgment under ambiguity — can you convert a vague prompt into a concrete, testable scope?
  2. Technical depth — can you explain why a component (e.g., a cache) solves a problem and what trade-offs it introduces?
  3. Communication — can you explain the design clearly while iterating?
  4. Collaboration — do you ask clarifying questions and validate assumptions with the interviewer?
Imagine two candidates given “design Instagram.” The first immediately draws a complex diagram of servers, caches, and shards. The second asks about user types, primary actions (uploads vs feed reads), and whether features like search or direct messages are in scope. By narrowing the scope (e.g., photos + home feed), the second candidate delivers a smaller, correct, and testable design in 45 minutes. Both candidates may know the same technologies, but the structured approach wins. Use a repeatable method to become that second candidate. Below is a six-step framework you can apply during the interview—use it as a checklist during the 45 minutes.
Use this six-step framework as your interview blueprint: clarify requirements, estimate scale, define APIs, create a high-level design, deep dive into the hardest parts, and identify bottlenecks and scaling strategies.
The six steps Step 1 — Clarify requirements (≈ 5 minutes)
Spend a few minutes converting the vague prompt into a concrete problem definition. Ask questions and state assumptions out loud so the interviewer can correct them. For a simplified Instagram scope, confirm whether the following are required:
  • Users can upload photos.
  • Users can follow other users.
  • Users can view a home feed populated by people they follow.
  • The feed should load quickly on open.
Write down assumptions (e.g., “no DMs, no search, photos only”) and verify them with the interviewer. Step 2 — Back-of-the-envelope estimation (≈ 5 minutes)
Estimate scale and workload characteristics so your design choices are grounded in numbers. Example assumptions:
  • 10,000,000 daily active users
  • Each user views ~100 photos/week and posts ~1 photo/week
  • Service is read-heavy (many more feed reads than uploads)
Use these estimates to guide decisions like caching vs denormalization. Always confirm numbers with the interviewer before relying on them.
A dark infographic slide titled "The Six-Step Framework" focusing on step 2: Estimate. It shows a mobile feed mockup, the figure "10,000,000 daily users" with usage stats (scrolls the feed 100/week, posts a photo 1/week) and a "Read Heavy" callout.
Step 3 — Define the APIs (≈ 5 minutes)
List a minimal set of APIs that satisfy your scoped features. For the simplified Instagram example:
These endpoints tell you what data to store: photos and metadata, follower graphs, and something to represent the home feed (materialized or computed). Step 4 — High-level design (≈ 10–15 minutes)
Draw a simple architecture diagram with boxes for the main components that satisfy the requirements. For our Instagram example include:
  • Mobile/web client
  • App servers (API layer)
  • User & follows database
  • Photo storage (object store)
  • Feed service (materialized feeds or on-demand computation)
  • CDN for serving images
Show how requests flow: upload → app server → object store + metadata DB; feed read → feed service/cache → CDN/client. Step 5 — Deep dive (≈ 10–15 minutes)
Pick 1–2 challenging components and go deep. For Instagram the home feed is typically the hardest problem:
  • How does a post from a user with 1M followers appear in those followers’ feeds?
  • Consider fanout strategies: push (write to each follower’s feed on write) vs pull (compute feed at read time).
  • Discuss write amplification, read latency, consistency, and how to hybridize push and pull for different user classes (e.g., push for low-fanout users, pull for celebrities).
A dark-themed infographic titled "The Six-Step Framework" showing a mobile app flow from a user phone to an app server and arrows pointing to a database and S3 bucket, with the "Deep Dives" step highlighted. Near the bottom is a portrait of a man in a red jersey labeled with a follower count and small "interviewer" and "you" icons.
Step 6 — Bottlenecks and scaling (last 5 minutes)
Call out the biggest bottlenecks and practical mitigation strategies. Prioritize the most likely pain points and give concrete fixes:
  • Follows database bottleneck — add caching, denormalize follower lists for frequent reads, or shard by user ID.
  • Photo storage throughput and capacity — store binaries in an object store and serve via a CDN.
  • Read-heavy traffic — prioritize read-optimized approaches (caching, materialized feeds) and avoid premature write-side complexity.
Summarize how your APIs map to storage and services: Close the interview with a 30–60 second recap: the scoped problem, the key APIs, the high-level components, the deep-dive decisions and trade-offs, and the major bottlenecks with mitigation plans. Now that you have the six-step framework, apply it to every system design question. Practicing this flow will help you make focused, testable designs and communicate them clearly under time pressure.

Watch Video