How would you design a URL shortener like bit.ly?
Assesses fundamental understanding of System Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Requirements: shorten a long URL, redirect quickly, handle ~100M new links per day with a 100:1 read-to-write ratio.
API: POST /api/links {longUrl} -> {shortUrl}; GET /{code} -> 301/302 redirect.
Key generation: base62 encode a global counter, or a distributed ID generator (Snowflake), or a random code with collision retry. Counter-based is compact and collision-free but predictable; random is unguessable but needs a uniqueness check.
Storage: a key-value store (DynamoDB/Cassandra) mapping code -> longUrl, plus a relational table for ownership and analytics. Reads dominate, so cache hot codes in Redis with a high hit rate.
Scale: stateless redirect service behind a load balancer, CDN/edge caching for popular links, read replicas, and async click analytics via a queue (Kafka) so logging never blocks redirects.
Extras: custom aliases, expiry, abuse detection, rate limiting, and 301 (permanent, cacheable) vs 302 (trackable) choice.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.