System Design Interview Questions for Senior Engineers

System design rounds are where senior and staff hires are won or lost, yet they are also the most inconsistently run interviews on most teams. The same candidate can pass with one interviewer and fail with another, simply because there was no shared rubric. A strong set of system design interview questions, paired with a clear view of what a good answer looks like, turns that round from a vibe check into a fair, repeatable signal.

TL;DR: Use these 30 system design interview questions, grouped from fundamentals to full designs. Each one comes with what a strong answer covers and the trade-offs to probe — so every interviewer grades the same way.

---

How to use system design interview questions the right way

The best system design interview questions reward process, not memorized architectures. Before drilling into any specific question, align your panel on what you are actually measuring.

Tip: A great system design answer almost always starts with the candidate asking you questions. If they jump straight to a database schema, that is a signal in itself.

What strong senior and staff candidates do, regardless of the prompt:

• Clarify before designing. They separate functional from non-functional requirements and confirm the read/write ratio and scale.
• Estimate roughly. They do back-of-the-envelope math to justify decisions instead of guessing.
• Sketch high-level first. They draw the big boxes, then drill into the one or two that matter.
• Name the trade-offs. They say what they are not solving and why, rather than pretending one design is universally best.

A repeatable rubric beats a clever question every time:
  1. Requirements & scope   →  did they negotiate, or assume?
  2. Estimation             →  sane orders of magnitude?
  3. High-level design      →  clean components, clear data flow?
  4. Deep dive + trade-offs →  did they defend choices under pressure?

Score each of those dimensions the same way for every candidate and the system design interview stops being a coin flip.

---

Fundamentals and trade-off questions

These warm-ups separate people who can recite definitions from people who can apply them. They work well in the first ten minutes and as quick calibration questions.

Key takeaway: At senior+ level, the right answer to almost every fundamentals question is "it depends — here's on what." Reward candidates who refuse a binary and explain the spectrum.

Strong questions to ask, and what a good answer covers:

• Functional vs. non-functional requirements. A good answer explains that non-functional needs (latency, availability, consistency) drive the architecture, and treats scoping as a negotiation, not a checklist.
• The CAP theorem in practice. Probe whether they understand the real choice is behavior during a partition — a ledger leans CP, a social feed leans AP — and that consistency is a spectrum, not a switch.
• Consistency models. Ask them to compare strong, eventual, and causal consistency and map each to a concrete product requirement. Session guarantees like read-your-writes are a staff-level signal.
• Back-of-the-envelope estimation. A good answer works in round numbers, derives QPS from daily active users, applies a peak multiplier, and uses the result to justify (or rule out) sharding.

Trade-offs to probe: do they reach for "strong consistency" reflexively, or only where the requirement demands it? Do they get lost in precise estimation math instead of letting it inform the design?

---

Scalability, storage, and caching questions

This is the heart of most system design interview questions for senior engineers — the candidate has to scale a system without hand-waving. Mix one easy opener with one hard follow-up.

Tip: "How would you scale this?" is too open. Anchor it: "Reads jump 50x but writes stay flat — what changes first?" Constrained questions surface real prioritization.

High-signal questions and what to listen for:

• Horizontal vs. vertical scaling. A good answer notes stateless services scale out easily and the hard part is always the stateful tier — and avoids premature sharding.
• Sharding and shard keys. Probe the shard-key choice: a poor key causes hotspots, scatter-gather queries, and painful rebalancing. Bonus for consistent hashing with virtual nodes.
• Caching strategies and stampedes. Ask them to compare cache-aside, write-through, and write-back, then ask how they would survive a hot key expiring under 10,000 concurrent requests.
• SQL vs. NoSQL. A good answer rejects the false dichotomy and justifies the choice by access patterns and consistency needs — often landing on polyglot persistence.

Cache-stampede defenses worth hearing in an answer:
  - request coalescing (one recompute, others wait)
  - early / probabilistic recompute before TTL
  - jittered TTLs so keys don't expire in lockstep
  - serve-stale-while-revalidate to protect the origin

Trade-offs to probe: do they quantify the read/write ratio before reaching for a tool? Do they raise cache invalidation and replication lag as the genuinely hard problems, rather than glossing over them?

---

API, communication, and reliability questions

Senior and staff engineers own the seams between services, so these questions reveal production scar tissue better than any whiteboard diagram. They also pair naturally with our backend developer interview questions when you want a deeper backend round.

Key takeaway: The reliability answers are where staff candidates pull ahead. Timeouts, circuit breakers, and idempotency are not trivia — they are the difference between a small incident and a full outage.

Questions worth asking, with the signal to grade on:

• Queues vs. synchronous calls. A good answer explains what a queue buys you (decoupling, load leveling, retries) and the cost it adds (eventual consistency, idempotent consumers) — and does not make everything async by reflex.
• REST, gRPC, and GraphQL. Listen for protocol matched to the client: gRPC for internal low-latency, GraphQL for flexible field selection, REST for simplicity and cacheability.
• Idempotency. Ask how they make "charge a card" safe to retry. Idempotency keys and conditional writes are the expected tools; recognizing which operations are naturally idempotent is the senior signal.
• Preventing cascading failures. Probe for timeouts, circuit breakers, bulkheads, and backoff with jitter — and whether they know naive retries amplify an outage.

Tip: Follow any reliability answer with "what does the user see while that's happening?" Graceful degradation and sensible fallbacks separate the theoretical from the battle-tested.

Trade-offs to probe: can they design for observability (metrics, logs, tracing) from the start rather than bolting it on after an incident?

---

Full system design questions, the main event

These open-ended prompts are the centerpiece. There is no single right answer — you are watching how the candidate decomposes a problem, defends choices, and handles the one nasty edge case you save for last.

Key takeaway: Every prompt below has a built-in discriminator — a follow-up that easily separates a textbook answer from a practical one. The celebrity-with-100M-followers twist on a news feed is the classic example.

Prompts that consistently produce signal:

• Design a URL shortener. A good answer covers code generation, a key-value store with aggressive caching, and the 301-vs-302 redirect trade-off. Twist: unique codes without a coordination bottleneck.
• Design a distributed rate limiter. Listen for token vs. leaky bucket vs. sliding window, a shared store with atomic increments, and a clear fail-open-vs-fail-closed decision.
• Design a news feed. The core trade-off is fan-out on write vs. read; a strong answer proposes a hybrid. Twist: the celebrity with 100M followers.
• Design a real-time chat system. Probe persistent WebSocket connections, routing a message to the recipient's server, and at-least-once delivery with client-side dedup.

Other proven full-design prompts in this bank:
  - typeahead / autocomplete   (trie + precomputed top-k, read-path latency)
  - web crawler                (URL frontier, politeness, dedup, traps)
  - file storage / sharing     (chunking, dedup, delta sync, metadata vs blobs)

Trade-offs to probe across all of them: do they separate the read path from the write path? Do they quantify scale before committing to an architecture? Do they handle the edge case you raise without throwing away their whole design?

---

Turn these system design interview questions into a structured round in Intervy

A great question list only helps if every interviewer uses it the same way. That is the gap a structured interview process closes — and what a technical interview platform like Intervy is built to enforce.

Tip: Store your model answers as the reference answer on each question. In live mode, interviewers can reveal it with a single keystroke when they need to calibrate mid-interview.

How the pieces fit together as a structured interview tool:

• Question bank. Keep every prompt in a color-coded, tagged bank with a Markdown reference answer and a difficulty level, so any interviewer can filter to the right questions in seconds.
• Reusable templates. Build an interview template once, add questions from the bank, drag to reorder, and duplicate it for the next loop — no copy-pasting docs.
• 1–5 scoring in live mode. During the interview, each question shows a 1–5 scale from Strong No to Strong Yes with an auto-saving comments field, and it is keyboard-first so the interviewer stays present with the candidate.
• Color-coded score cards. Afterward, an interview scoring tool view rolls every question up into green/yellow/red cards summarizing the rating and comments, so debriefs compare apples to apples.

Key takeaway: Consistent questions plus a shared 1–5 scale plus side-by-side score cards is what makes two interviewers agree on the same candidate — the whole point of a structured round.

Want more questions or a fast write-up? Every account starts with 300 free AI credits, an AI question generator can turn a prompt into questions with answers and metadata, and an AI-drafted summary can speed up the debrief. Prefer your own provider? Connect your own AI key and those requests go straight to it.

---

Getting started

You do not have to rebuild this question set by hand. Core interview management is free, so you can stand up a structured system design round today.

All 30 questions are also available as a ready-to-import set in Intervy. Head to the Export / Import page, select "System Design Interview" from the Sample Interview Data dropdown, and click Load — organized by category, tagged by difficulty, and ready to drop into your next interview template.

What you get the moment the import finishes:

• A ready question bank. All 30 prompts land color-coded by category, tagged by difficulty, each with its model answer attached as the reference answer.
• A head start on templates. Filter the bank, pick the questions for a given level, and assemble a reusable system design template in minutes.
• Consistent scoring from day one. Run the round in live mode on the 1–5 scale, then compare candidates on color-coded score cards.

Tip: Import the set, build one template from it, and run your next loop entirely on the 1–5 scale. The first debrief where two interviewers actually agree is when the structure pays for itself.