Get an invite

Design a URL shortenerSystem design interview practice, out loud

A voice interviewer that follows your reasoning, on a canvas you both see. Here is the brief, the numbers you can ask for, and what the interview goes into.

  • System design
  • 30 minutes
  • Suggested for Junior and Mid, open at every level
Practise this one out loud

Private beta · 30 free minutes when you're in

A desktop browser and a microphone.

The brief

The interviewer reads it out, then waits for you.

Interviewer
“Design a URL shortener. Someone pastes a long link and gets a short one back; anyone who opens the short link lands on the original page. Start wherever you like; the canvas is yours.”

The numbers you can ask for

The interviewer answers these when you ask, and never volunteers them. For anything else it says the brief doesn't fix that: choose an assumption and say it out loud.

You askThe interviewer answers
How many new links?100 M new short links a day
How many redirects?10 B redirects a day, about 100 per link created; peaks at 2× the average
How long do links last?5 years by default; a creator may set an earlier expiry
How long is a long URL?100 characters on average, 2 KB at most
What may a short code contain?Letters and digits only; as short as practical
How fast must a redirect be?99 in 100 redirects under 100 ms, not counting the user's network
Availability?Redirects 99.99 %, link creation 99.9 %
Where are the users?Global; clicks come from every continent
Is X in scope?In: shorten, redirect, optional custom alias, optional expiry, a click count per link. Out: accounts, editing a link's target, analytics beyond the count, link previews

Be ready for these

The interviewer starts with the requirements and ends with the wrap-up. In between, it follows you, so the order is yours. The answers are yours too: this page doesn't give them.

  1. What exactly are you building, and what numbers must it hold?First
  2. Which calls does the service take, what goes in, and what comes back?
  3. How is every short code unique, and how short can it be?
  4. Where does a link live, and how is it found?
  5. How does a click become the long URL, fast, at the read volume?
  6. What does a link carry beyond its target, and what can go wrong with it?If there's time
  7. Where is your design weakest, and what would you build first?Last
  8. Can someone follow your canvas without you there to explain it?Throughout

What's expected at your level

Your Report reads you against the bar for the level you pick. Each level keeps what's below it and adds a line.

See all twelve bars →
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • Judged only if the interviewer asks about it, at Junior.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • Judged only if the interviewer asks about it, at Junior.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
Technical depth
  • Explains what one technology does in the design, and why it fits.
Communication
  • On the final canvas, every box is named and joined to its flow.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
  • +Names the requirement that would change the architecture, and what would change.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
  • +Names the figure that limits the design, and says why.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
  • +Names the part that changes first as the system grows, and what it becomes.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
  • +Says how the schema or an API changes without breaking clients.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
  • +Names what fails first at ten times the load, and the fix.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
  • +Says how a failure is kept from spreading, and what keeps working meanwhile.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
  • +Names the decision that is hardest to reverse, and why.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
  • +Shows how one of those limits shaped a choice.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
  • +Answers each question in its first sentence, then gives the detail.

Thirty minutes. Out loud. On this brief.

Pick your level when you start. Pause for coaching if you get stuck, and read your Report a few minutes after.

Private beta · 30 free minutes when you're in

Other interviews

System design · 30 or 45 min · every level

Design a chat app

People send text messages to each other from a phone or a laptop.

System design · 30 or 45 min · Mid to Staff

Design a video platform

People upload a video from a phone or a laptop, and anyone can watch it — on a slow connection, on a TV, anywhere in the world.