Lesson 12 of 15
31. Design a URL Shortener

Score yourself

3 min read+10 XP

Score yourself

Give yourself 0, 1 or 2 points per row.

Area0 points1 point2 points
RequirementsStarted drawingListed featuresFeatures and qualities, agreed and written down, scope trimmed
EstimatesNoneNumbers, not used laterNumbers that drove decisions (cache, no sharding yet)
API and dataSkippedEndpoints or table, not bothBoth, with error cases and the code as primary key
High-level designMissing piecesBoxes, no walkthroughEvery requirement walked through the boxes
Deep diveHand-wavedOne option describedOptions compared, a pick with reasons
Trade-offsNone namedNamed when askedRaised unprompted ("because, cost, unless")
CommunicationLong silencesMostly clearThought out loud, checked in, managed time

12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.

The bar: fresher vs SDE-2

FresherSDE-2
CodesBase62 of a counter, explained clearlyCompares counter, hash and random; handles collisions, guessability and ID blocks
ScaleAdds a cache because reads dominateSizes the cache, handles hot keys and penetration
RedirectsKnows it's a redirectPicks 301 vs 302 from the requirements
AnalyticsCounter in the databaseAsync events, at-least-once, lag agreed with the interviewer
FailureMentions replicasWalks each component's failure and fallback

Common mistakes

  • Hashing the URL with MD5, cutting it to 6 characters, and not mentioning collisions.
  • Writing a click counter to the database on every redirect.
  • Sharding on day one for 3 TB and 40 writes a second.
  • Choosing 301 by habit, then promising click analytics.
  • Forgetting abuse: a public shortener with no rate limit becomes a spam tool.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz