System design basics

It is not testing whether you have built a system at that scale. Almost no candidate has. It is testing whether you can take an under-specified problem, impose structure on it, make defensible decisions under uncertainty, and communicate all of that clearly to another engineer in forty minutes.

That reframing matters, because it tells you where the marks are. A candidate who produces a modest but coherent design, states what each choice costs, and drives the conversation will outscore one who name-drops technologies without connecting them to requirements. Saying "I would use Kafka here" is worth nothing on its own; saying "writes are bursty and the consumer is slower than the producer, so I would put a queue between them, accepting the added latency and operational complexity" is the whole game.

Weighting rises sharply with seniority. For SDE-1 this round is often informational. For SDE-2 it is a real gate. At senior and staff level it is usually the round that decides the level you are offered, and sometimes whether you get an offer at all.

Drive the conversation through these steps rather than jumping to a diagram. The single most common failure in this round is starting to draw boxes in the first two minutes.

Budget your forty minutes roughly: five on requirements, five on estimation, five on the API, ten on the high-level design, ten to fifteen on whichever deep dive the interviewer picks, and a few minutes to wrap up. Say the plan out loud at the start. Announcing structure is itself a positive signal, and it stops you from being led off track.

Never start designing from the prompt as given. "Design Twitter" is deliberately underspecified, and the questions you ask are scored. Separate functional requirements from non-functional ones, write both down where the interviewer can see them, and get explicit agreement before moving on.

Then narrow aggressively. You cannot design all of Twitter in forty minutes and the interviewer does not want you to. Propose a scope — "I will focus on posting and the home timeline, and treat search and notifications as out of scope unless you want them" — and let them redirect. Proposing scope is a senior signal; asking permission for everything is not.

Estimation exists to justify your architecture. If you skip it, every subsequent choice sounds arbitrary, and when the interviewer asks why you sharded, you have no answer. Keep the arithmetic crude and round aggressively — nobody wants precision, they want the order of magnitude.

The standard chain: start from daily active users, multiply by actions per user per day to get daily requests, divide by about one hundred thousand seconds in a day to get average QPS, then multiply by two to five for peak. For storage, multiply the write rate by the size per record by the retention period. For bandwidth, multiply QPS by average payload size.

A worked example: ten million daily actives each making twenty reads and two writes gives two hundred million reads and twenty million writes a day, which is roughly two thousand reads and two hundred writes per second on average, maybe five thousand and five hundred at peak. If each write stores one kilobyte, that is twenty gigabytes a day, or about seven terabytes a year. Those three numbers now justify a cache, a read replica strategy, and a sharding conversation.

A few endpoints anchor the whole design and force you to be concrete about what the system does. Three or four is enough. Name the method, the path, the key parameters, and what comes back.

This step also surfaces design decisions early. Pagination strategy — offset versus cursor — matters at scale and cursor-based is the correct answer for a feed. Idempotency keys on writes matter if clients retry. Mentioning these unprompted is a strong signal that you have operated a real system.

Now draw. Keep it to the components you can justify from the requirements: clients, a load balancer, one or more application services, the datastore, a cache, and a queue if you have asynchronous work. Do not add a component you cannot explain the need for — every unjustified box is an invitation to a question you will not answer well.

Walk the interviewer through a single request end to end, then a single write end to end. Tracing one concrete path through the diagram is much clearer than describing each box in isolation, and it exposes gaps in your own design while you still have time to fix them.

Storage choice is where interviewers probe hardest, because it is where candidates parrot received wisdom. "NoSQL scales better" is not an answer. The honest position is that the choice depends on your access patterns, your consistency needs, and the shape of your relationships.

Relational databases give you transactions, joins, and strong consistency, and modern ones scale a lot further than candidates assume. Document and wide-column stores give you flexible schemas and easy horizontal partitioning, at the cost of joins and often of strong consistency guarantees. Key-value stores are the right answer for simple, high-throughput lookups. The deciding question is usually: what are my top three queries, and which store answers them without a join across shards?

Sketch the actual tables or documents with their key fields. A concrete schema is far more convincing than a shape labelled "database", and it lets you talk about the index you would add and what it costs on writes.

Caching is the most common answer to a read-heavy system and the place where superficial answers show. Be specific about which layer you are caching at — client, CDN, an application-level cache like Redis, or the database query cache — because they solve different problems.

Then handle the hard part, which is always invalidation. Say what your eviction policy is, what your TTL is, and what happens on a write: do you invalidate the entry, update it, or let it expire? Mention the failure modes — a thundering herd when a hot key expires, cache stampede on cold start, and the staleness window your users will actually see. Candidates who bring up invalidation unprompted stand out immediately.

Start with the cheap moves and escalate only as your numbers demand. Vertical scaling is legitimate and underrated; say so rather than jumping straight to a distributed design. Then read replicas, which solve read-heavy load simply and introduce replication lag you must acknowledge. Only then sharding.

When you shard, the shard key is the entire decision. Pick one that distributes evenly and keeps the queries you care about inside a single shard. Then name the problem it creates: cross-shard queries, hot shards from celebrity users, resharding as you grow, and the loss of cross-shard transactions. Every real sharding scheme has a painful case, and naming yours is what separates a designed system from a drawn one.

Anything that does not have to happen before the user gets a response should not. Fan-out to followers, sending email and push notifications, generating thumbnails, updating analytics — all of it belongs behind a queue.

A queue buys you decoupling, burst absorption, and retries. It costs you eventual consistency, operational surface, and a new class of bug. Be ready for the follow-ups: how do you guarantee delivery, what happens to a message that fails repeatedly, and are your consumers idempotent? Dead-letter queues and idempotent consumers are the expected answers and are worth saying before you are asked.

You do not need to have built a planet-scale system; you need to reason about the levers. For every choice, say what you gain and what you give up. Naming the cost is the signal — a design presented as free of downsides reads as one you have not thought about.

Most candidates design the happy path and stop. Spending the last few minutes on what happens when things break is a cheap, reliable way to look more senior than the average interviewee.

Walk through single points of failure in your own diagram and say how each is mitigated. Mention what you would monitor and alert on — not "monitoring", but the specific signals: p99 latency, error rate, queue depth, replication lag. Mention rate limiting to protect the service, and graceful degradation: if the recommendation service is down, serve a generic feed rather than an error page.

Work through the canonical prompts and talk each one end to end as if you were being interviewed. Out loud is not optional — the gap between a design that feels clear in your head and one you can narrate coherently is enormous, and the round tests the second one.

Time-box strictly to forty minutes, including the requirements phase you will be tempted to rush. Record yourself occasionally; it is uncomfortable and it will show you exactly where you ramble, where you go silent, and where you skipped a justification.

The failures in this round are remarkably consistent, and almost all of them are process failures rather than knowledge gaps.