Design a URL shortener

"Design a service like bit.ly. A user gives us a long URL and we hand back a short one. Anyone who visits the short one ends up at the original."

That is the whole prompt, and it is deliberately thin — the first thing being assessed is whether you fill the gaps yourself or start drawing boxes.

Work through it the way an interview goes: agree what you are building, size it, design the interface, choose where the data lives, decide how it scales, and say what breaks first. Six questions, and you will get a scorecard at the end naming which of the six was weakest.

There is no single right architecture here. There are answers you can defend and answers you cannot, and every option below tells you which it is once you have committed.

Step 1 of 6

Requirements gathering

Which of these belong in the requirements you agree before designing anything?

The prompt gave you two sentences. Before any box is drawn, you have to turn that into something you can be held to.

Pick everything that genuinely shapes the design. Leave out the things that sound thorough but change nothing — reciting a long list is a common way to spend five minutes and learn nothing about the system.

This scenario leans on Caching, SQL and NoSQL and Consistent Hashing. Reading one first is a recommendation, never a requirement — and doing the lab cold then reading is a perfectly good order.