Phase 6
Interview Prep
A structured way to tackle any design question.
Pause & reflect
Before you read on, answer this in your head — or on paper:
You have 45 minutes. The question is "Design a URL shortener."
How do you spend the time? What do you draw first? When do you go deep vs stay high-level?
The framework
1. Requirements clarification
Questions to ask: Functional: What features? Edge cases? Non-functional: Latency, availability, scale. Extended: Analytics? Monitoring? Rate limiting? Requirements are often vague — clarifying early avoids rework. Spend 2–3 min; don't over-clarify.
2. Estimation & constraints
Scale the system: DAU, read/write ratio, RPS, storage for 5–10 years. Example: 100M URLs/month × 500 bytes × 120 months ≈ 6 TB. Round numbers; show reasoning. Check assumptions with the interviewer.
3. Data model
Define entities and relationships. URLs: hash, longURL, createdAt, userId. Index on hash. Consider SQL vs NoSQL based on access patterns. Schema shapes your API and flows.
4. API design
Define interfaces: createURL(originalURL, expiration?), getURL(shortURL). Keep it simple; come back for extended features. Example: createURL returns short URL string; getURL returns long URL or 404.
5. High-level design
Client → LB → API servers → DB + Cache. Draw the flow for create and redirect. Monolith vs microservices? Add load balancers, replicas. Discuss tradeoffs aloud.
6. Detailed design
Deep dive on 2–3 areas. Key generation: Base62, hash, counter, or KGS. Caching: LRU, 80/20 rule. Sharding: Consistent hashing. Present pros/cons; back decisions with reasoning.
7. Bottlenecks & mitigations
SPOF? DB overload? Cache availability? Add replicas, sharding, multiple cache instances. Read company eng blogs for their stack and priorities.