This is the question that gets butchered more than any other in system design prep. Most resources hand you a 5-minute toy answer suitable for a phone screen and call it done. In a real onsite, this question runs 50 to 60 minutes, and the interviewer is using it to probe at least four distinct skills: capacity reasoning, ID generation under distributed constraints, caching strategy, and your awareness of failure modes. Miss two of the four and you fail the round, regardless of how clean your boxes-and-arrows came out.

This walkthrough is the senior version. If you are prepping for L4 / mid-level the bar is lower — you can stop after Step 5. For L5 / senior and L6 / staff, the deep dives are where the round is won or lost.

The Question

“Design a URL shortener service like bit.ly. The service takes a long URL and returns a shorter alias that, when accessed, redirects to the original.”

This question turns up in essentially every system design loop — Amazon, Google, Twitter / X, Reddit, Stripe, Pinterest, and most Series B+ startups doing senior-and-up hires. It is popular because it is a bounded problem with multiple defensible architectures, which makes it a good lens on how you think rather than what you have memorized.

Step 1 — Clarify Before You Draw

Three questions before you draw a single box. Ask these out loud, even if you think you can guess the answer. Spending ninety seconds here is what produces the senior signal.

1. Read-to-write ratio? The almost-universal answer is somewhere between 100:1 and 1000:1. Most short URLs get clicked many more times than they get created. This number drives every caching decision later in the round, so you need it pinned down.

2. Custom short codes allowed, or system-generated only? This question splits the design in half. System-generated only: you can use auto-incrementing IDs and have no collision problem at all. Custom codes allowed: you have a uniqueness check on every write, plus a hot-key problem because everyone wants short, memorable aliases like /sale or /promo.

3. Analytics required? Click counts, geographic data, referrer tracking? If yes, this is no longer a key-value problem. It becomes a key-value problem plus an event pipeline plus an aggregation system. The interviewer is testing whether you spot that the analytics requirement reshapes the architecture.

A senior candidate writes the answers to these three questions on the whiteboard. A junior candidate skips this step, designs for the wrong assumptions, and has to restart twenty minutes in.

Step 2 — Estimate

Pick numbers that justify your architecture. Imprecision is fine; sloppiness is not.

Working assumptions for the rest of this walkthrough:

• 100M new URLs created per month, which gives roughly 40 writes per second on average, with peaks 5 to 10x higher

• 100:1 read-to-write ratio, giving roughly 4,000 reads per second on average, with peaks above 40K

• 5-year retention horizon

• Average record size: 100 bytes for the long URL, 7 bytes for the short code, plus metadata — call it 500 bytes per record

Storage: 100M × 12 × 5 = 6 billion URLs over five years. At 500 bytes per record that is 3 TB. This fits comfortably on a single sharded relational database. You do not need anything exotic.

Bandwidth: 4,000 reads per second × 500 bytes is about 2 MB/s of read traffic. Trivial.

The estimation is not decoration. You will reference these numbers four more times before the round ends — when you justify caching, when you justify sharding, when the interviewer asks “what if we 100x’d the traffic?” Every later trade-off comes back to these inputs.

Get Access to GitHub Repo

Read more

“Didn’t demonstrate sufficient depth.” “Wanted to see stronger technical judgment.” “Good fundamentals but the design wasn’t production-ready.”

None of these tell you what to fix. They’re descriptions of an outcome, not a diagnosis.

After building prep material for engineers targeting L4–L7 at FAANG-tier companies, I’ve spent a lot of time understanding what interviewers actually score — not what they say they score, not what the official rubric says, but what the scorecard entries look like in practice.

Here’s what I’ve found.

The scoring dimensions most engineers don’t know about

The system design interview at most major tech companies is scored on 5–8 explicit dimensions. Two of them, almost everyone knows about:

Technical correctness — did the candidate’s design actually solve the stated problem? Could it work in production?

Depth — did the candidate go beyond the surface answer on at least one component?

The dimensions that separate candidates who barely pass from candidates who get “Strong Hire” are the ones most prep resources ignore:

Subscribe for Question Walkthrough

Problem scoping

The interviewer is watching whether you negotiate the scope of the problem before you start designing. Not ask questions — negotiate scope.

There’s a difference between “what’s the expected scale?” (a question) and “I’m going to focus on the timeline and the fan-out architecture, acknowledge that notifications and search exist, and go deep on the hardest part — does that work for you?” (a negotiation).

Candidates who score well on this dimension don’t try to design everything. They explicitly choose what they’re designing and why, and they do this in the first 3–5 minutes.

Candidates who score poorly try to design everything and end up designing nothing deeply. The 50-minute interview is not enough time to produce depth across a system with the surface area of Twitter. Everyone who attempts it runs out of time before the interesting parts.

Communication clarity

This dimension is scored throughout the round, not at any specific moment. The question: can the interviewer follow your reasoning in real time?

The failure mode is surprisingly common among technically strong candidates: they know what they’re building, but they don’t say it out loud. They draw boxes on the whiteboard and connect them with arrows, and the interviewer has to ask “why did you connect those two boxes?” to understand the design decision.

The fix is specific: every decision should be stated before it’s drawn. Not “here’s a Redis cache” while drawing — “I’m going to put a Redis cache in front of Postgres here because the read:write ratio is 100:1 and the hot read pattern is point lookups by user_id, which Redis handles well at sub-millisecond latency. So here’s the cache.” The decision, then the reasoning, then the diagram.

This sounds slow. It’s actually faster, because the interviewer is never confused about what you’re doing or why. Confusion is the time-killer, not explanation.

Operational maturity

This is the dimension that most separates L5 from L6 scorecards.

An answer that lacks operational maturity designs a system that works on the happy path. Everything goes right. The database responds. The messages are delivered. The cache is warm.

An answer with operational maturity designs a system and then asks: what happens when it breaks?

“The failure mode here is the thundering herd when the Redis node recovers. Without jitter on the retry logic, every request that failed during the outage retries simultaneously the moment Redis comes back. I’d add exponential backoff with ±20% jitter to spread the retry load.”

“I’m targeting p99 < 100ms for the feed read. The leading indicator I’d alert on is cache hit ratio dropping below 90% — that tells me Postgres load is about to spike before users start feeling degraded latency.”

These additions take 30 seconds to say. They produce a measurable difference in how the round is scored.

Level calibration

Interviewers are calibrating your answer against the level you’re being hired for. A brilliant answer that’s calibrated for L4 will not earn a Strong Hire at L6. An adequate answer calibrated correctly for L5 can earn a Hire at L5.

This is worth saying explicitly: you don’t need to demonstrate the maximum possible depth. You need to demonstrate the right depth for your level.

At L4, the bar is: run the framework correctly. Estimate. Design the read and write paths. Mention at least one deep dive.

At L5, the bar is: defend your decisions under probing. Name failure modes. Cover the hard part of the question — the thing that makes this question different from the trivial version.

At L6, the bar is: SLOs with monitoring signals. Cross-system trade-offs. Operational layer. The three things above, plus the “what would tell me this design is failing” for each major component.

Knowing your level and calibrating your answer to it is itself a scored dimension.

The one thing most guides don’t tell you

The design round is not a knowledge test. It’s a judgment test.

Two candidates can produce completely different architectures for the same question and both get Strong Hire. Two candidates can produce very similar architectures and one gets Strong Hire while the other gets No Hire. The architecture is the medium. The judgment — in how you scope, how you communicate, how you reason under pressure, how you handle failure cases — is what’s being evaluated.

This changes how you should prepare.

Memorizing architectures is necessary. It’s not sufficient. The prep that moves the needle is timed practice under interview conditions, with feedback specifically on the four dimensions above — not just on whether your architecture was technically correct.

Every Tuesday, this newsletter publishes one full named-question walkthrough: the exact answer that would earn a Hire signal at your target level, plus the follow-up probes interviewers actually use, plus the common mistakes that fail the round. It covers what the architecture is, why each decision was made, and what the interviewer is specifically looking for.

The first ten questions are published.

https://systemdr.systemdrd.com/subscribe

The free archive has a question bank, the six-step framework cheatsheet, and the estimation numbers reference. All three are downloadable without a subscription.

— Sumedh