A messaging app wants its own link shortener. Every link shared in chats goes through it, so the read side dwarfs the write side, and a single viral link can take a large share of all traffic for an hour.
You own the service end to end: code generation, storage, redirects and click analytics.
The traffic#
- 10 billion links stored over five years; 40 million new links a day at launch.
- Redirects: 200,000 a second on a normal evening, peaking at 1.2 million a second during a festival sale.
- One campaign link once took 8% of all redirects for 40 minutes.
- Click counts per link must be visible to the link owner within a minute.
The hard parts#
- Short codes that never collide, without a single counter becoming the bottleneck.
- Partitioning 10B rows so a redirect is one lookup, and so growth doesn't mean a painful reshard.
- A hot key that would melt one shard and one cache node.
- Counting clicks without putting a write on the redirect path.
What to submit#
Write it like the whiteboard half of an interview, in markdown:
- Requirements you'd confirm first (functional and non-functional), and what you'd leave out.
- Estimates: the back-of-the-envelope numbers that drive the design (QPS, storage, bandwidth).
- API and data model: the few calls and tables/keys that matter.
- High-level design as at least one Mermaid diagram.
- Deep dives on the two hardest parts, with the failure modes and how you contain them.
- Trade-offs: what you chose, what you gave up, and what would make you change your mind.
Keep it under ~2,500 words. Diagrams beat paragraphs.