🏗️ System Design Interview Coach

System Design Walkthrough: URL Shortener

A system design interview framework is a structured 7-step approach calibrated to 45-minute interview time budgets, designed to demonstrate the breadth of senior engineering thinking. Based on 200+ interview sessions, candidates who followed the 7-step structure passed FAANG L5 interviews at ~65% vs. ~25% for unstructured answers — the structure is ~40 percentage points of outcome. URL shortener is the #2 most common system design prompt; your answer benchmarks well against ~10,000 documented interviews.

Time Budget (45 min)

Step 1: Clarify (5 min)

Ask the interviewer:

1. What's the scale? (DAU, URLs/day, reads per URL — frames everything else)

2. Is URL lifetime finite (7 days, 1 year, forever)? (affects storage)

3. Custom URLs supported? (changes ID generation)

4. Analytics needed? (adds data pipeline requirements)

5. Global or single-region? (geo-distribution consideration)

Do NOT ask: 'what tech stack?' — that's your decision to make.

Step 2: Estimate (5 min)

Assume: 100M URLs/day, 100:1 read:write ratio, store forever.

• Writes: 100M/day = ~1,200 writes/sec. Peak ~10k/sec.
• Reads: 10B/day = ~120k reads/sec. Peak ~1M/sec.
• Storage: 100M × 500 bytes × 365 days × 10 years = ~180 TB. Affordable.
• Bandwidth: 120k reads × 500 bytes = ~60 MB/sec. Modest.
• Cache size (80/20 rule): top 20% of URLs = 80% of reads. ~24B URLs cached × 200 bytes = ~5 TB across cache cluster.

Key insight: read-heavy at 100:1. Cache aggressively.

Step 3: API (5 min)

Core endpoints:

POST /shorten
  body: { long_url, optional: custom_alias, expire_date }
  returns: { short_url, short_code }

GET /{short_code}
  returns: 301 redirect to long_url (or 302 if analytics needed)

GET /stats/{short_code}
  returns: { clicks, countries, referers }

Auth: API key required for /shorten. /{short_code} is public (no auth) but rate-limited.

Step 4: Data Model (5 min)

Core table (URL mapping):

urls:
  short_code: varchar(7) PK
  long_url: text
  created_by: uuid (user id)
  created_at: timestamp
  expires_at: timestamp (nullable)

Storage choice: NoSQL (DynamoDB or Cassandra) over SQL.

• Why: Key-value read pattern (short_code → long_url). No joins. Scale matters more than ACID for this workload.
• Tradeoff: lose relational queries for user-analytics; acceptable because analytics are secondary pipeline.

ID generation: pre-generate IDs via counter service (e.g., Redis INCR + base62 encode) for guaranteed uniqueness. Don't rely on random hashing + collision-check — at 100M/day the birthday paradox creates collisions.

Step 5: Components (10 min)

[User]
  │
  ├──→ [Load Balancer / CDN]
  │         │
  │         ├──→ [Read path: /{short_code}]
  │         │       → [Redis Cache] (99% of reads)
  │         │       → [URL Database] (cache miss, 1%)
  │         │       → redirect
  │         │       → [Analytics pipeline (async)]
  │         │
  │         └──→ [Write path: /shorten]
  │                 → [App server]
  │                 → [ID generator (Redis counter)]
  │                 → [URL Database write]
  │                 → [Populate cache]
  │
  └──→ [Rate limiter (Redis)]

Key decisions:

• CDN in front for geographic distribution of reads.
• Redis cache between LB and DB for 99%+ read-hit rate at this ratio.
• Analytics async (Kafka → data pipeline). Doesn't block redirect.

Step 6: Scale + Bottlenecks (10 min) ⚠️ Seniority signal

What breaks first at 10x scale?

1. Read throughput on DB — mitigated by cache + read replicas. But cache miss penalty matters. Pre-warm cache via background job of recent URLs.

2. ID generator single point. Redis counter bottlenecks at ~100k/sec write peak. Mitigation: range-based ID allocation — each app server gets 10,000 IDs at a time, uses them locally, requests next range. Removes counter from critical path.

3. Hot short_codes in cache. Viral links = cache key becomes hot. Mitigation: consistent hashing across cache nodes so hot keys distribute. (This is one of your weak areas — study consistent hashing specifically before interview.)

4. Global reads. Single-region setup adds latency for international users. Mitigation: multi-region deploys + CDN + read replicas. Writes can stay in primary region (write rate is low).

5. Abuse / spam. Bad actors create millions of short links. Mitigation: rate-limit /shorten per API key + per IP. Captcha for high-volume creation.

6. Analytics pipeline. At 120k redirects/sec, async write load to analytics pipeline. Mitigation: Kafka as buffer, downstream consumers process in batches.

Step 7: Tradeoffs (5 min)

• NoSQL vs. SQL for URL table: NoSQL for scale; tradeoff is losing user-analytics joins (solved via separate analytics store).
• 301 vs. 302 redirect: 301 (permanent) is cacheable by browsers — reduces our load. 302 (temporary) lets us track every click. Choose based on analytics priority. Most shorteners use 302 to track.
• Cache strategy: write-through vs. read-through. Read-through simpler; write-through guarantees freshness. Go read-through + populate-on-write.
• Counter-based IDs vs. hash-based: counter gives sequential IDs (guessable) but no collisions. Hash-based is harder to guess but requires collision-check. Counter + base62 encode is standard answer.

The 4 Interview Failures (Avoid These)

1. Skipping estimation. 'I'll just design generically' → auto-downgrade. 5 min of math is non-negotiable.

2. Diving too deep into one component. Spending 20 min on ID generation algorithm while skipping multi-region = junior signal.

3. No explicit tradeoffs. Every design choice should be paired with 'the tradeoff is X.'

4. Waiting for interviewer prompts. Senior candidates drive the interview. 'Next I'll cover API design' then go.

If Stuck

If stuck on a component (common for your weak areas — consistent hashing, geo-distribution):

• Acknowledge: 'I'd need to think carefully about this; let me describe the approach even if details are fuzzy.'
• Sketch the approach: 'I'd use consistent hashing to distribute keys across cache nodes; the specific algorithm I'd research, but the goal is avoiding hot shards on popular URLs.'
• Move on. Don't spend 10 min trying to recall details.

Key Takeaways

• Drive the interview. Announce each step before entering it. 'Next, I'll do back-of-envelope estimates.'
• Estimate before API. ALWAYS. Skipping this is the #1 L5 miss.
• Bottleneck discussion is the seniority signal. Spend 10 min on 'what breaks at scale' — that's where L5 vs. L4 is scored.
• Prep consistent hashing + geo-distribution specifically. These are your weak areas and likely to come up at L5.