System design

4 deep-dive scenarios, step-by-step breakdowns, architecture patterns.

0/11 covered

System Design quiz

12 questions, 80% to pass

URL Shortener (Bit.ly)

Medium · 35-40 min

Functional requirements

  • Given a long URL, generate a short URL (6-7 chars)
  • Given a short URL, redirect to the original URL
  • Support custom short URLs (optional)
  • Track analytics: clicks, geolocation, device

Non-functional requirements

  • 100M URLs created/day, 10B redirects/day
  • Redirect latency under 10ms P99
  • High availability (99.99% uptime)
  • URLs should not be predictable (no sequential IDs)

Scale estimates

  • 100M writes/day = ~1,200 writes/sec
  • 10B reads/day = ~115,000 reads/sec (100:1 read:write ratio)
  • 500 bytes/URL x 100M/day x 365 days x 5 years = ~90TB storage

How one request moves through it

URL shortener redirect pathRedirect is a cache lookup; the click event leaves the hot path over Kafka. Request path: Browser to Load balancer to Redirect service to Redis.hit 80%+missBrowserCDNcaches 301sLoad balancerRedirect servicestateless, N replicasRedisshort_code → urlPostgresread replicasKafkaclick eventsClickHouseanalytics
Redirect is a cache lookup; the click event leaves the hot path over Kafka.Stateless serviceCacheDatabaseQueue / streamOne request

Define the contract before the architecture. Two endpoints: POST /shorten (body: {long_url, custom_alias?}) returns {short_url}. GET /{short_code} issues a 301/302 redirect to long_url.

Key decisions

  • • 301 (permanent) vs 302 (temporary) redirect: 301 reduces load because the browser caches it, 302 allows accurate analytics tracking. Choose based on requirements.
  • • Authentication: the public API needs rate limiting; the business API needs auth tokens.

Key components

Load balancer

Distributes 115K req/sec across stateless app servers

ID generation service

Snowflake-style unique IDs without coordination

Redis cache

80%+ cache hit rate makes redirect sub-millisecond

SQL database (read replicas)

Persistent storage; read replicas handle read scale

Kafka + analytics DB

Async click tracking without impacting redirect latency

CDN (optional)

Edge caching for 301 redirects reduces origin load globally

Trade-offs to discuss

  • • 301 vs 302: 301 is faster (browser caches), 302 gives better analytics.
  • • SQL vs NoSQL: SQL is simpler and sufficient; NoSQL if multi-region write scale is needed.
  • • Hashing vs counter: hashing has collisions; a counter requires a central sequence generator.

Expected follow-up questions

  • • How would you handle URL expiration?
  • • How do you prevent abuse (spam or malicious URLs)?
  • • How would you design this for 10x the scale?
  • • How do you handle custom domains (company.short.link)?

How this round is scored

CriterionWeak answerStrong answer
Requirement negotiationStarts drawing boxes before asking anything, and never establishes the read to write ratio.Pins the 100:1 read to write ratio, the 10ms P99 redirect target and whether custom aliases are in scope, then says which of those drives the design.
Tradeoff articulationSays "use Redis" with no reason, and picks 301 or 302 without naming what it costs.Frames 301 versus 302 as caching versus analytics fidelity, and base62 on a Snowflake ID versus hashing as collision risk versus a central sequence.
Team and delivery implicationsTreats the design as one undifferentiated build.Splits the work into an ID service, a redirect path and an analytics pipeline, and notes the analytics pipeline can ship after launch.
OperabilityNo numbers on cache behaviour, and no answer for what happens when Redis is cold.States the target hit rate, how hot keys are pre-warmed, and what the miss path costs the database at 115K reads per second.
CommunicationJumps between layers, and leaves the whiteboard unreadable.Drives the request left to right once, labels each hop with its latency budget, and pauses for the interviewer at each decision.