Technical Interview Prep · 14 min read

System Design Interview Questions: A Senior Engineer's Guide

System design rounds don't reward the candidate who names the most technologies. They reward the candidate who reasons out loud, quantifies the workload, picks a boring architecture, and can defend every trade-off. This guide walks the exact framework strong candidates use at Google, Meta, Amazon, and Stripe — plus the distributed-systems trade-offs behind every good answer.

1. The 6-step framework

Every strong system-design answer follows roughly the same arc. Spend the first ten minutes on steps 1–3; most candidates skip to boxes-and-arrows immediately and never recover.

Clarify requirements. Functional (what users can do) and non-functional (SLOs, consistency, availability, cost). Confirm scope out loud.
Estimate the workload. DAU, QPS, read:write ratio, payload size, storage growth per year. This drives every later decision.
Define the API. A handful of endpoints or RPCs with request/response shapes. Grounds the discussion.
Sketch the high-level design. Client → LB → stateless service → data layer. Add caches, queues, CDNs only when the numbers demand them.
Deep-dive one component. Interviewer usually picks. Pick the hardest yourself if they don't — storage schema, sharding key, cache invalidation.
Address bottlenecks and failure modes. Hot keys, thundering herds, retries, backpressure, region failover, data loss windows.

2. Distributed-systems trade-offs

Interviewers don't want a "correct" architecture — they want you to name the trade-off you just made. Memorise these eight and reach for them by name.

Trade-off	When it matters
Consistency vs Availability (CAP)	A partitioned system can be consistent or available, not both. Payment ledgers pick C; social feeds pick A.
Latency vs Throughput	Batching raises throughput but adds tail latency. Interactive APIs prefer smaller batches; analytics jobs prefer larger ones.
Strong vs Eventual Consistency	Strong needs coordination (Paxos/Raft) and costs latency; eventual is cheap but forces you to design for stale reads.
Read-heavy vs Write-heavy	Read-heavy loves caches and replicas; write-heavy needs sharding, LSM storage, and careful hot-key handling.
SQL vs NoSQL	SQL wins on transactions and ad-hoc queries; NoSQL wins on horizontal scale, flexible schemas, and predictable single-key access.
Sync vs Async	Sync gives immediate feedback and simpler error handling; async (queues, streams) absorbs load spikes and decouples failure domains.
Push vs Pull	Push is fast but wastes work on inactive consumers; pull scales gracefully but adds polling latency.
Vertical vs Horizontal scaling	Vertical is easy until it isn't; horizontal is the only real long-term answer but forces you to think about partitioning early.

3. The 10 questions to prepare

These ten cover ~80% of what FAANG-tier loops throw at senior candidates. For each, be able to give a 45-minute answer covering all six framework steps.

Design a URL shortener (bit.ly)
Design a rate limiter
Design a distributed cache
Design a news feed (Facebook / Twitter timeline)
Design a chat / messaging system (WhatsApp)
Design a video streaming service (YouTube / Netflix)
Design a ride-sharing app (Uber)
Design a search autocomplete / typeahead
Design a metrics / monitoring system
Design a payments / ledger system

4. Worked example: design a rate limiter

Requirements

Limit each API key to N requests per minute across a globally distributed fleet. Reject over-limit requests with HTTP 429. p99 added latency < 5ms. Must survive a single-region outage.

Workload

100k RPS peak, 10M API keys, ~10 rules per key. Read-heavy: every request checks the limit, few writes reset counters.

Design choice

Token-bucket algorithm stored in a sharded in-memory store (Redis Cluster) keyed by {apiKey}:{ruleId}. Each edge PoP checks locally first with a Lua script (atomic decrement + TTL) to keep p99 low; a background job reconciles counters across regions every second.

Trade-offs to name out loud

Consistency: we accept small over-limit bursts (~1–2%) across regions to keep availability during partitions — this is a deliberate AP choice.
Hot keys: a viral tenant can hammer one shard; mitigate with local approximation + periodic reconciliation, not synchronous cross-shard writes.
Failure mode: if Redis is unreachable, fail open (allow) or fail closed (block)? For a paid API, fail closed on auth-critical rules, fail open on soft-limit rules.

5. The senior-level mistakes

Skipping estimation. If you don't state QPS and storage growth, every downstream choice is unjustified.
Over-engineering. Reaching for Kafka + Cassandra + Kubernetes on day one signals junior taste. Start boring; add complexity when the numbers force it.
Name-dropping without depth. "I'd use Kafka" without explaining partitioning, retention, or consumer-group semantics loses the point instantly.
Ignoring failure modes. Every dependency will fail. If your design has no retry, no timeout, and no degraded mode, the interviewer knows you've never been on call.
Not driving the conversation. The interviewer is grading whether you'd be trusted to lead a design review. Own the whiteboard, propose the deep-dive, defend the trade-off.

6. Practising with targeted feedback

Reading system-design guides has a ceiling. What actually moves the needle is speaking a design out loud, on the clock, with someone probing the weak trade-off. Generic prep tools give you the same generic bank of questions regardless of your background — RoleMatch reads your CV and the specific job description, then generates system-design probes tuned to that role's stack, scale, and seniority.

You get a RoleMatch scorecard after each session — a per-answer score on framework adherence, whether you named trade-offs, whether you addressed failure modes, plus filler words and speaking pace. Unlike generic mock-interview sites, the feedback is specific to what a distributed-systems interviewer would grade you on.

Run a system-design mock

Upload your CV + the JD. Get a scored system-design interview tuned to that role's stack.

Start a mock interview →See pricing