There is no best design
"What's the best database?" has no answer. "What's the best database for 10 writes a second, strict consistency and a team that already knows Postgres?" does. A design is only good relative to its requirements, and every choice improves one thing by making another worse.
That's why interviewers care so much about trade-offs. Anyone can list components. Knowing what each one costs, and when the cost is worth paying, is the skill.
The trade-offs you'll meet most
| You can have more… | …but you pay with | Example |
|---|---|---|
| Consistency | latency and availability | Waiting for every copy to confirm a write before answering. |
| Read speed | write speed and storage | Each extra index or precomputed copy speeds reads and slows writes. |
| Availability | cost and consistency | More copies in more places, which may disagree for a moment. |
| Low latency | freshness | Serving from a cache means sometimes serving old data. |
| Flexibility | simplicity | Splitting into many services lets teams move apart, and adds network calls and failure modes. |
| Control | your time | Running your own database versus paying for a managed one. |
You'll meet each of these properly in Part 2. For now, notice the shape: nothing on the left is free.
A small trade-off with big effects: 301 or 302?
When someone opens a Snip link, Snip answers with an HTTP redirect. There are two common kinds:
- 301 Moved Permanently tells the browser "this short link always goes there". Browsers remember it, so the next time the same person clicks, the browser goes straight to the long URL without asking Snip.
- 302 Found (a temporary redirect) tells the browser "go there this time". Every click comes back to Snip.
Step through what happens when the same person clicks a link twice:
5 messages. Use Next and Back to follow them in order.
Text version
- Browser → Snip: GET /x7Kp — First click: the browser asks Snip where the short link goes.
- Snip → Browser: 301 → example.com/… (reply) — Snip counts the click and answers with a permanent redirect. The browser stores it.
- Browser → Long URL's site: GET example.com/… — The browser follows the redirect.
- Note over Browser: later: same person clicks again
- Browser → Browser: cached 301 — The browser already knows where /x7Kp goes, so it doesn't ask Snip at all.
- Browser → Long URL's site: GET example.com/… — Straight to the long URL. Fast for the user, and Snip never sees this click.
So the choice is a trade-off:
| 301 (permanent) | 302 (temporary) | |
|---|---|---|
| Repeat clicks | Skip Snip entirely | Always go through Snip |
| Load on Snip | Lower | Higher |
| Speed of repeat clicks | Faster | One extra round trip |
| Click counts | Miss repeat clicks | Every click counted |
| Changing the target later | Hard: browsers cached the old one | Easy |
Which is right? It depends on the requirements. Snip promised owners click counts (01.02 Functional and non-functional requirements), so Snip uses 302, and pays for it with more traffic, which the estimate in 01.05 Back-of-the-envelope estimation says it can afford. A shortener with no analytics might rightly choose 301.
A link shortener's main selling point is accurate click analytics. Which redirect should it return?
How to talk about a trade-off
A good answer has four parts. Use it whenever you make a choice in a design:
- The options: "We could return a 301 or a 302."
- What each buys and costs: "301 cuts our load but loses repeat clicks; 302 counts everything but every click hits us."
- The choice and the requirement behind it: "Owners need click counts, so 302."
- What would change your mind: "If we dropped analytics, or load became a problem, I'd revisit it."
The fourth part is what makes it sound like judgement rather than a memorised answer.
Recap
Interview questions
Should a URL shortener return a 301 or a 302 redirect?