System design interview: a 45-minute answer structure

You hear "Design a URL shortening service" and get an empty whiteboard. The task sounds simple, so your hand reaches to draw a box labeled "database." Twenty minutes later there are six boxes on the board, the interviewer asks how many requests per second this design can handle, and you haven't calculated that once.

In AI reviews of Sobes users' interviews, system design comes out as the hardest stage: the average success rate is 52%, against 61% for technical interviews. And the tasks go well beyond feeds and chats. The question bank has, for example, "Design a semantic search system over 1M corporate documents" and "Design a personalized product recommendation system for a marketplace". You can't memorize answers to every variant, but you can memorize the order in which any answer is built.

The 45-minute plan

Out of an hour, about forty-five minutes usually go to the task itself. The rest is introductions and your questions.

The boundaries are approximate. If the interviewer pulls you into sharding details at minute twenty, follow them: they're showing you what they want to assess.

Requirements and load: the first ten minutes

Start with questions. Functional: what exactly the system does and what's out of scope. Non-functional: how many users, what matters more during a failure, availability or consistency, what latency is acceptable.

Let me fix the scope first. We need creating a short link and redirecting. Do we do custom aliases, expiration, and click statistics? If time is tight, I'd keep the first two plus expiration and discuss statistics at the end.

You propose what to cut yourself. The interviewer sees that you can bound a problem instead of trying to design everything at once.

Then the numbers. Precision doesn't matter, the order of magnitude does, and you should calculate it out loud:

Say 100 million links are created per month. A month is roughly 2.6 million seconds, so that's about 40 writes per second. Links are read far more often than created. I'll take a hundred to one: 4,000 redirects per second, and I'll plan for double that at peak. Over five years that's 6 billion records. At half a kilobyte per record, that's about 3 terabytes.

Half of the design decisions follow from these three numbers. Writes are small and reads dominate, so you need a cache in front of the storage. Three terabytes is awkward for a single server, so sharding will come up.

API and data

Write the API as signatures, without extra detail:

POST /links        { url, ttl? }  ->  { code }
GET  /{code}       ->  302 Location: url

The data model here is one table: code, url, created_at, expires_at. Lookups always go by key and there are no relations, so a key-value store works, or a regular relational database sharded by code. State your choice and the reason in one sentence. A technology without a reason won't earn you credit.

Say separately where code comes from. Seven base62 characters give about 3.5 trillion combinations, a large margin for 6 billion records. There are two ways to generate it: a counter encoded in base62, or a random string with a collision check. A counter has no collisions, but the codes are predictable and you need a shared source of numbers. Pick one and explain why.

The diagram

Now you can draw. Client, load balancer, several stateless service instances, cache, storage. Walk both scenarios through the diagram out loud: what happens when a link is created and what happens when someone follows it.

Redirect: the request lands on any instance, which checks the cache. If the code is there, we return a 302 right away. If not, we go to the database, put the result in the cache, and respond. Popular links will almost always be cached, so only a small share of reads reaches the database.

A request path spoken aloud is worth more than extra boxes. It shows that the design works and that you know why each element is there.

Bottlenecks and trade-offs

At minute thirty, ask yourself the interviewer's question before they do: what breaks first if the load grows tenfold.

• Storage: sharding by code, read replicas.
• Cache: what happens if it goes down and all traffic hits the database.
• Code generator: one counter for everyone, or number ranges handed out to each instance.
• One "hot" link that gets half of the traffic.

Name trade-offs directly, with their price:

I return 302 instead of 301. The browser won't cache the redirect, so every click comes to us. The load is higher, but we can count statistics and disable a link. If statistics aren't needed, 301 is cheaper.

In the last minutes, summarize: what's on the board, what you simplified, and what you'd add with more time (cleanup of expired links, abuse protection, monitoring).

Common mistakes

• Drawing from the first minute. Without requirements and numbers there's nothing to justify the design with, and you end up redrawing it.
• Staying silent. The interviewer evaluates your reasoning, and the board doesn't show it. The same skill matters in live coding, covered in Live coding interview: what to say while you code.
• Skipping load estimates. Then caches, shards, and queues appear "because that's how it's done."
• Naming technologies without reasons: Kafka, Redis, and Cassandra in one sentence and not a single "because."
• Designing a perfect system for a billion users when the requirements say ten thousand.
• Defending your first solution to the end. If the interviewer finds a hole, agree and rework the design.

If you're asked about a technology you haven't used, don't fake experience. How to reason in that situation is shown in Don't know the answer in an interview?. Where system design sits among the other stages is covered briefly in the article on passing a technical interview.

How to practice

Set a timer for 45 minutes and solve one task end to end using the table above, saying everything out loud. The first attempts look the same for almost everyone: by minute thirty only the requirements and half of the diagram are ready. Two or three timed repetitions fix that.

In the system design trainer you draw the diagram on a canvas, and the interviewer asks questions about it and gives a review at the end. Solve two different tasks there and compare which parts of the plan are weak in both. Usually it's the load estimates and the bottlenecks, and those are the ones worth drilling separately.