How to Explain a URL Shortener in English

The prompt

Design a URL shortener like bit.ly. In 60–90 seconds, in English, cover the two API calls, how you generate the short code, where you store it, and one thing that breaks at scale.

How to explain it

1. 1. Requirements

   Who the user is, and what must work on day one.

   Clarify identity, write vs read, and one thing you are not building yet.

2. 2. Scale

   One rough number you can say out loud.

   QPS, storage, or “millions of keys.” The number can be rough. The sentence cannot be missing.

3. 3. API

   Name the two or three calls.

   “I would expose allow(userId) and a 429 when they are over the limit.”

4. 4. Data

   Where the state lives.

   Cache, database, or log. Say why that store, not a tool dump.

5. 5. Bottleneck

   What breaks first when traffic grows.

   Hot key, single leader, clock skew. Invite a follow-up.

6. 6. Trade-off

   What you gain and what you give up.

   Accuracy vs speed, consistency vs availability. One pair is enough.

• “I would start with two calls: create, and redirect.”
• “Reads are the scale problem, so I would cache popular codes.”
• “The bottleneck is a viral link hitting one key.”

Practise out loud

Model spoken script

I would start with two calls: create a short link, and redirect on GET. I need unique codes and a fast read path. I would generate a compact ID, encode it, and store long URL to code in a key-value store. Reads are the scale problem, so I would cache popular codes. The bottleneck is collisions if the generator is naive, or a hot key on a viral link. The trade-off is a random ID — simpler, uglier — versus a counter, which is sequential and easier to guess.