What is a System Design Interview

What is a System Design Interview

A system design interview (often called the SDI, or the "design round") is a 45–60 minute open-ended conversation where you are handed a deliberately vague prompt — "Design a URL shortener", "Design Twitter's timeline", "Design a rate limiter" — and asked to architect a working, scalable system out loud. Unlike a coding interview, there is no compiler, no single correct answer, and no green checkmark. You are graded on how you think: how you turn ambiguity into concrete requirements, how you reason about scale, and how you defend your trade-offs.

The problem it solves for the company is simple. Senior and staff engineers spend most of their time not writing tight algorithms but deciding where data lives, how services talk, what breaks at 10x traffic, and which failure is acceptable. A coding screen cannot observe that judgment. The SDI is a proxy for the daily reality of building and evolving distributed systems.

How it works, precisely

Almost every strong SDI follows the same skeleton, and interviewers expect you to drive it. Treating the interview as a structured process — not a brain-dump — is itself part of the signal.

• 1. Requirements clarification (~5 min). Split into functional requirements (what the system does: shorten a URL, redirect, show analytics) and non-functional requirements (the properties: availability, latency, consistency, durability). Nail down read-heavy vs write-heavy and what "scale" means here.
• 2. Back-of-the-envelope estimation (~5 min). Convert vague scale into numbers: users, QPS (queries per second), storage growth per year, bandwidth. These numbers justify every later decision.
• 3. API + data model (~5 min). Define a handful of endpoints and the core entities/schema. This anchors the abstract system to something concrete.
• 4. High-level design (~10 min). Draw the boxes: clients, load balancer, application/service tier, databases, caches, queues. Show the request flow end to end.
• 5. Deep dive + scaling (~15 min). The interviewer picks one component and probes: how do you partition (shard) the database? Where do you add a cache and how do you keep it fresh? How do you handle hot keys, replication, and failure? This is where seniority shows.
• 6. Bottlenecks + wrap-up (~5 min). Identify single points of failure, discuss monitoring, and name what you'd revisit with more time.

Crucially, this is a dialogue. The interviewer steers, injects new constraints ("now it's 100x bigger"), and expects you to adapt rather than recite a memorized answer.

A concrete worked scenario: "Design a URL shortener"

Watch how estimation drives design. Suppose the interviewer says "assume 100 million new URLs created per day."

• Write QPS: 100M / 86,400s ≈ ~1,160 writes/sec (round to ~1.2K).
• Read QPS: redirects vastly outnumber creations. Assume a 100:1 read:write ratio → ~116K reads/sec. Why 100:1 and not 10:1? A link is written once but clicked for years — it keeps earning redirects from chats, tweets, and docs long after creation, so reads accumulate over the link's whole lifetime while the write happened exactly once. Defend the shape, not the digit: anywhere from 50:1 to 500:1 tells the same story — read-heavy, so a cache is not optional.
• Storage: ~500 bytes/record × 100M/day × 365 × 5 years ≈ ~91 TB over five years. One machine won't hold it → you must shard. And don't just assert the 500 bytes — derive it: 7-byte short key + ~200 bytes of long URL + 8-byte user id + two 8-byte timestamps (created, expiry) ≈ 230 bytes of raw fields, then roughly double for primary-key index entries, row headers, and page slack → ~500 bytes. An interviewer who asks "why 500?" is checking whether the input was reasoned or memorized.
• Key space: a 7-character base62 code gives 62⁷ ≈ 3.5 trillion unique keys — comfortably enough for years.

Now the design falls out of the numbers. Reads at 116K/sec with tiny, immutable records are a perfect fit for an in-memory cache (Redis) fronting the database, plausibly serving 90%+ of redirects from memory in <5 ms. Writes go through a service that generates a unique key (via a pre-generated key range or a counter like a ZooKeeper/Snowflake-style ID) and stores the mapping in a partitioned key-value store. The read path and write path are asymmetric — and the estimates are what proved it. (This same 100M-URLs arithmetic is unpacked line by line, with anchor tables and estimation drills, in Back-of-the-Envelope Estimations — here we only need the conclusions it forces.)

Surviving the injected constraint: "now make it 100×"

The pitfalls below name "not adapting to injected constraints" as a red flag — so model the adaptation once. The interviewer says: "Great. Now it's 10 billion new URLs a day." Re-run the numbers and watch which component breaks first:

• Reads: 116K → ~11.6M reads/sec. The cache saturates first — a single Redis node tops out around 100K–1M simple ops/sec, so it was already near its ceiling at 1×. The cache must become a tier sharded by key hash (dozens of nodes), and one viral link can still melt the single shard that owns it → replicate the hottest keys into an in-process cache at the app tier.
• Writes: 1.2K → ~116K writes/sec. Now the key generator is the bottleneck: a single coordination-backed counter (the ZooKeeper-style sequence above) handles on the order of 10K writes/sec — an order of magnitude short. Fix: pre-partitioned key ranges — each app server leases a block of, say, 1M keys and hands them out locally, so coordination happens once per million keys instead of once per write.
• Storage: 91 TB → ~9.1 PB over five years. "Shard it" stops being an answer at petabyte scale; you now need a lifecycle policy: most links go cold within weeks, so expire by TTL or migrate dormant mappings to cheap object storage, keeping only the hot working set on the fast tier.

The order is the insight: the cache node saturates at roughly 2–8× today's read load, the key generator near 10×, storage only over years. Saying "at 100× the cache tier breaks first, here's why, here's the fix" — instead of defending the original sketch — is exactly the signal the injected constraint exists to test.

Trade-offs: when to lean which way

The SDI is really a test of whether you can name a trade-off and pick a side for this problem. A few recurring axes and how to reason about them:

• SQL vs NoSQL. Choose relational (PostgreSQL/MySQL) when you need transactions, joins, and strong consistency — payments, inventory. Choose NoSQL (Cassandra, DynamoDB) when the access pattern is a simple key lookup at massive write scale and you can tolerate eventual consistency — like the URL mapping above. Not a religious choice: match the store to the access pattern.
• Strong vs eventual consistency (CAP). During a network partition you can keep the system available or keep it strongly consistent, not both. Bank balance → favor consistency. Like-count or follower-count → eventual is fine and buys you availability and speed.
• Cache vs no cache. Add a cache for read-heavy, tolerance-for-staleness data. Skip it (or use write-through) when data must be exact and writes dominate — a cache there just adds an invalidation headache.
• Sync vs async (message queue). Use a queue (Kafka, SQS) to decouple slow work — sending emails, generating thumbnails — so the user's request returns fast. Don't add a queue to a path that needs an immediate, consistent answer; it adds latency and delivery-semantics complexity.

The meta-rule: there is no "best" architecture, only the one that fits the stated requirements. Saying "I'd use eventual consistency here because a slightly stale view count is acceptable and availability matters more" scores higher than any specific technology name.

Pitfalls an interviewer probes

Interviewers are trained to poke exactly where weak candidates fold. Watch for these:

• Jumping to a solution without requirements. Diving into databases before asking scale or read/write ratio signals you'll over- or under-engineer real systems. Always clarify first.
• Skipping the estimation. If you can't show why you need a cache or a shard, your design looks like pattern-matching. The numbers are your justification.
• Hand-waving "just add a cache / just scale horizontally." The follow-up is always how: cache invalidation strategy, hot-key problem, consistent hashing for shard rebalancing, replication lag. Vague answers collapse here.
• Ignoring failure and single points of failure. A design with one load balancer, one DB primary, and no replication is not production-ready. Expect "what happens when this box dies?"
• No prioritization of requirements. Trying to build everything (analytics, auth, custom aliases) in 45 minutes means you finish nothing. State assumptions, cut scope out loud, and go deep on the core.
• Not adapting to injected constraints. When the interviewer says "now 100x the traffic," they're testing whether your design bends or breaks. Rigidly defending your first sketch is a red flag.

What separates a senior pass from a staff pass on the same prompt? Depth of initiative. A senior pass executes the skeleton competently: breadth once across the whole design, then depth wherever the interviewer points. A staff pass volunteers the next layer unprompted — names the failure modes before being asked ("this cache tier is a thundering-herd risk if a hot key expires"), attaches a cost to the design ("keeping five years hot is ~91 TB on fast storage; archiving cold links shrinks that to the working set"), and says which requirement they would push back on. The full catalogue of anti-signals — the behaviours that cap a score regardless of the design — lives in Things to Avoid During the System Design Interview; this page's job is the arc itself.

Key takeaways

• A system design interview grades judgment under ambiguity, not a single correct answer — it's a proxy for the daily work of senior engineers making distributed-systems trade-offs.
• Drive a structured flow: clarify requirements → estimate (QPS, storage) → API + data model → high-level design → deep-dive scaling → bottlenecks. The estimates justify every design choice.
• Score points by naming trade-offs and picking a side for this problem (SQL vs NoSQL, strong vs eventual consistency, cache vs none, sync vs async) rather than reciting technologies.
• Avoid the classic tells: solving before clarifying, hand-waving "just add a cache," ignoring failure modes, and refusing to adapt when the interviewer changes the scale.