Building blocks: the 14 ideas in every answer
The concepts an HLD answer is assembled from, with the SDE-1 bar and SDE-2 depth for each.
Every high-level design answer is built from the same small set of ideas. Learn them once, and a new problem becomes a matter of choosing and combining. Read this page in week 4, then keep it open while you watch the beginner playlist.
Priority for SDE-1
You need the SDE-1 bar for all 14 blocks. The SDE-2 lines are marked so you can skip them now. Two to three hours a week is enough at this stage.
Requirements and scope
Write down what the system does and what it will not do. Ask for the core actions, the user count, the read to write ratio and any latency target. Say the out-of-scope list early, so the interviewer corrects you before minute 40.
SDE-1 must: name three features, one constraint and one non-goal in three minutes. SDE-2 later: quantify the non-goals, such as "two seconds of cross-region lag is fine".
The System Design Primer has a short section on outlining use cases and constraints.
Back-of-envelope estimation
One million requests a day is about 12 per second, since a day is roughly 100,000 seconds. Peak traffic is 2 to 3 times the average. One million rows at 1 KB each is 1 GB, so a year of that is 365 GB before indexes. Round to powers of ten and say the number out loud.
SDE-1 must: produce QPS and one year of storage in two minutes. SDE-2 later: turn those numbers into node count, headroom and cost.
ByteByteGo's estimation chapter lists the standard numbers and latencies.
API design
Write three to five endpoints with a method, a path and the key fields. Use nouns for resources and put the verb in the method. Decide pagination and the error shape before you are asked. Add an idempotency key (a unique ID that makes a retry safe) to every write a client might retry.
SDE-1 must: sketch four endpoints and name the status codes for success, bad input and conflict. SDE-2 later: versioning and partial failure in batch calls.
Alex Xu's API design piece covers these choices clearly.
Data model and database choice
Start from access patterns, not entities. Write the two queries the system runs most, then pick a store that serves them cheaply. A relational database covers joins, transactions and constraints, which is most interview problems. A document or key-value store fits one blob per key, read by key alone.
SDE-1 must: name the tables, the primary key and one relationship. SDE-2 later: justify the choice against one alternative store.
The Primer also has a SQL versus NoSQL section that lists those tradeoffs plainly.
Indexing and sharding
An index is a sorted copy of columns that speeds reads and slows writes. Index what you filter and sort on, and read the query plan instead of guessing. Sharding splits rows across machines by a shard key, so pick one with high cardinality that spreads writes evenly.
SDE-1 must: name one index and say why the shard key was chosen. SDE-2 later: rebalancing, hot partitions and changing a shard key.
ByteByteGo's sharding crash course covers range, hash and directory sharding.
Caching
A cache is a copy of data held closer to the reader: browser, CDN edge, app memory, database buffer pool. Caching is easy; invalidation is the hard part. Use a short TTL for data that changes, and delete the key on write when stale reads are unacceptable.
A stampede (many requests hitting the database when one hot key expires) is fixed with request coalescing or jittered expiry.
SDE-1 must: place one cache, pick a TTL, and say what staleness the user sees. SDE-2 later: hot keys and consistency between cache and store.
TwoHardThings is a two-minute note on why invalidation stays hard.
Load balancing
A load balancer spreads requests across servers and stops sending traffic to unhealthy ones. Layer 4 balances connections and is fast but blind. Layer 7 reads the request, so it can route by path and retry elsewhere. Health checks make the pool self-healing.
SDE-1 must: put a balancer in front of the service tier and explain the health check. SDE-2 later: least connections versus round robin, and draining connections during deploys.
The Primer covers active-passive and active-active pools.
Queues and streams
A queue delivers each message to one worker, which spreads slow work. A stream is an append-only log that many consumers read at their own position, and it can replay. Logsmith is a stream, which is why it supports replay and consumer groups. Both usually promise at-least-once delivery, so a handler that moves money must deduplicate.
SDE-1 must: name one task to move off the request path, and what happens when the worker is down. SDE-2 later: ordering per partition and consumer lag.
ByteByteGo on Kafka versus RabbitMQ explains when each model fits.
Consistency and CAP
CAP says that during a network partition you choose consistency or availability. Most systems choose availability and accept stale reads briefly. Outside a partition the real trade is latency against freshness, which PACELC adds. Say which data must be strongly consistent and which can lag.
SDE-1 must: name one dataset of each kind. SDE-2 later: your store's partition behaviour and its read-your-writes guarantee.
ByteByteGo's CAP guide is worth one read, because the term is misused constantly.
Replication and failover
Replication keeps copies of the data on more than one machine. A leader takes writes and followers replay its log. Async replication is fast and can lose the last writes on failover; sync replication is safe and slower. Failover promotes a follower, and split brain is when two nodes both think they lead.
SDE-1 must: add a read replica and say how much lag is acceptable. SDE-2 later: quorum writes, automatic failover and the data loss window.
ByteByteGo's replication guide covers single-leader, multi-leader and leaderless.
Idempotency and retries
A retry is safe only when repeating the operation gives the same result. Store the idempotency key with the response, and replay that response when the key arrives again. Back off exponentially with jitter, and cap the attempts.
This is Ledgerline's core idea. A transfer retried after a timeout must not move money twice.
SDE-1 must: explain why a POST needs a key and where the key lives. SDE-2 later: deduplication windows and retries across service boundaries.
ByteByteGo on idempotency connects keys, retries and exactly-once claims.
Rate limiting
A rate limiter caps requests per client per window. Token bucket allows short bursts and is the usual default. Fixed windows let a client double its rate at the boundary, which is why sliding windows exist. Enforce at the gateway, key it by user or API key, and return 429 with a Retry-After header.
SDE-1 must: pick an algorithm, the limit and the key. SDE-2 later: distributed counters and per-tier limits.
Arpit Bhayani's sliding window writeup includes the implementation and its cost.
Observability
Observability is how you learn what the system is doing without guessing. Logs record events, metrics record numbers over time, and traces follow one request across services. Alert on symptoms users feel, such as error rate and latency, not on CPU. One slow trace teaches more than a dashboard of averages.
SDE-1 must: name the three signals and one alert. SDE-2 later: sampling, cardinality and SLO alerting.
AWS's observability guidance treats these as design questions.
Tradeoff narration
Every choice has an alternative and a cost. The sentence that scores is: "I chose X over Y because of Z, and it costs W." Without the cost, the interviewer hears a preference. Keep a few tradeoffs from your own work ready, such as Postgres over a queue for the outbox.
SDE-1 must: attach a cost to two decisions per answer. SDE-2 later: compare three options under a stated constraint.
Hello Interview shows how strong candidates keep tradeoffs visible.
The one-page answer skeleton
Reuse these eight steps in any HLD round. They fit on one page and take about 40 minutes to speak.
- Restate the problem in one sentence, then ask two clarifying questions.
- Write scope: three core features, one non-goal, one constraint.
- Estimate average QPS, peak QPS and storage for one year.
- Draw the API: four endpoints with method, path and key fields.
- Choose the data model, the database and the shard key.
- Draw the read path: client, balancer, service, cache, database.
- Draw the write path: service, queue, worker, retries, idempotency.
- Name two failure modes and one accepted tradeoff. Then stop.
The last step is the one most candidates skip, and the one that separates an SDE-1 answer from an SDE-2 one.
Common mistakes
- Say the number before the technology. "100k writes a day, so one Postgres primary" beats "we need Kafka".
- Draw the simple path first, then add components when a constraint demands them.
- Use your own projects as the example whenever a concept matches one.
- Practise out loud with a timer. Silent reading hides the gaps.