Design a URL Shortener, stage 9 of 9: defend it
Defend the simple design
Your interviewer pushes back: "This wouldn't scale. I'd expect Cassandra for the links, Kafka for clicks, a dedicated ID-generation service, and separate microservices for creation, redirect and analytics. Why didn't you do that?"
System so far· 8 parts
Select a component to see what it is responsible for and which state it owns.
- 1Clickers → CDN edge: GET /aZ3kQ9x
- 2CDN edge → Redirect service: Cache miss
- 3Redirect service → Postgres: Look up code
- 4Customer dashboard → Links API: Create, edit, disable
- 5Links API → Postgres: Insert with unique code
- 6Redirect service → Click stream: Click event (fire and forget)
- 7Click aggregator → Click stream: Read click batches
- 8Click aggregator → Postgres: Upsert daily aggregates
- Request / response
- Asynchronous
What you need to know
0 of 1 checks done
"Would this scale?" is a question about numbers, so answer with numbers. For each component the interviewer suggests, say two things:
- What it would buy you. Every one of those components solves a real problem.
- The trigger. Which measurement would tell you it's time to add it.
That shows you know what each component is for, without adding them all up front.
Check
Which is a good trigger for moving the links from Postgres to a partitioned store like Cassandra?