1. Apply your framework to a toy system
You’re going to run your system design framework end to end on a very simple prompt: “design a URL shortener.”
The goal here is not to be clever about URL shortening; it’s to practice your ordered reasoning.
Think of your framework as a fixed sequence of questions you always walk through. A simple version:
- Clarify the problem
- Define requirements
- Call out assumptions and constraints
- Propose a high-level design (components + data)
- Walk a request through the system
- Call out tradeoffs and risks
You’ll practice that whole loop and capture it in one page of text or a rough sketch.
1.1 Clarify the problem from the prompt
You start from the raw prompt:
“Design a URL shortener.”
You must narrow this into something concrete, otherwise your design floats.
Write down 3–5 clarifying decisions, for example:
- Who is this for?
- e.g. “Public web app like bit.ly, anyone can shorten links.”
- What is the core function?
- “Given a long URL, create a short URL; when people hit the short URL, redirect to the long one.”
- Is it just HTTP links, or others (deep links, files)?
- Decide one: “Only HTTP/HTTPS URLs.”
- How long should short URLs be?
- e.g. “8–10 characters in [0–9, a–z, A–Z].”
- Is user login/accounts required?
- e.g. “No accounts; anonymous use is fine” (or the opposite, but be explicit).
Put these as bullet points at the top of your page under a heading like “Problem clarification”.
This step matters because every later choice (DB schema, caching, consistency) depends on what you think “URL shortener” actually means.