Home / Blog / System Design URL Shortener: Interview Talk Track

System Design URL Shortener: Interview Talk Track

Published 2026-10-09 · Luna Interview

A system design URL shortener interview talk track is a classic mid-level opener: clear APIs, heavy read skew, and a short-code uniqueness problem. Candidates commonly report this prompt at product companies because it forces encoding choices, redirect latency, and abuse controls without drowning you in social-graph complexity. This guide gives you a structured script from clarifying questions through capacity, data model, and tradeoffs.

Clarify before you draw

Do not invent a billion-user product in silence. Ask:

• Read vs write ratio? (usually redirects ≫ creates)
• Custom aliases allowed?
• TTL / expiry for links?
• Analytics needed (click counts, referrers)?
• Same long URL → same short code, or unique every time?
• Latency target for redirect (e.g. p99 under 50–100ms)?
• Auth: public create vs logged-in only?

Talk track:

“I’ll assume high read skew on redirects, optional custom aliases, no hard TTL unless you want one, and basic click counts. Redirects should be fast and cacheable; create can be a bit slower.”

Write assumptions on the board. Interviewers correct scope early when you invite it.

APIs (keep boring)

• POST /v1/urls { longUrl, customAlias?, ttl? } → { shortCode, shortUrl }
• GET /{shortCode} → 302/301 to long URL
• Optional: GET /v1/urls/{shortCode}/stats

Discuss 301 vs 302: 301 is cacheable aggressively by browsers/CDNs (good for permanent); 302 keeps control if you may change the target. Candidates commonly report interviewers accepting either with a reason.

Capacity estimate (order of magnitude)

Pick round numbers and show the method:

• 100M new links / month ≈ ~40 creates / sec average (peak 5–10×)
• 10B redirects / month ≈ ~4k redirects / sec average (peak much higher)
• Storage: 100 chars average long URL + metadata ≈ ~200B/row → 100M rows ≈ ~20GB (+ indexes, replicas)

Talk track:

“Writes are modest; reads dominate. I’ll design for thousands of redirects per second with caching, and treat create as a lower QPS path with uniqueness enforcement.”

If they give different scale, redo the arithmetic out loud. The skill is flexibility, not the specific billions.

Short-code design

Common options:

Interview default many candidates use: distributed unique ID → base62 encode to ~7–8 characters (62^7 is large enough for many years at moderate create rates). Mention collision checks if you choose random.

Custom aliases: separate uniqueness constraint; reserve reserved words; rate-limit.

Redirect path (the hot path)

1. Receive short code
2. Lookup code → long URL (cache first)
3. Emit 302/301 with Location
4. Async or sampled analytics increment

Talk track:

“Redirect is cache-aside on shortCode. On miss, read primary store, populate cache with TTL. Click counting is async so it does not block the redirect.”

Data model (minimal)

Table urls:

• short_code (PK)
• long_url
• user_id (nullable)
• created_at, expires_at
• is_active

Optional clicks aggregate or event stream. Do not design a full warehouse in the first pass unless asked.

Caching and CDN

• Cache shortCode → longUrl in Redis/Memcached
• Hot links dominate: size cache for working set, not all time
• CDN in front of GET redirects for public links if 301 and cache headers allow
• Invalidate or short TTL on update/disable

Stampede: coalesce misses on a viral code.

Uniqueness and create path

Create flow:

1. Validate URL (scheme, length, malware denylist ideally)
2. Generate code (ID encode or random)
3. Insert with uniqueness constraint; retry on conflict
4. Optionally write cache
5. Return short URL

If same long URL should map to one code, store a hash index of long URL → code and reuse.

Sharding (only when scale needs it)

Start with one primary + replicas. When range grows:

• Shard by hash(short_code) or by ID ranges
• Keep redirect lookup single-shard (code is the key)
• Analytics can be a separate pipeline

Do not draw six databases before one works.

Abuse, safety, and product edges

Mention briefly—shows senior taste:

• Rate limits on create
• Phishing / malware URL checks
• Disable/tombstone API
• Predictable codes → enumeration risk (longer codes or auth on create)
• GDPR/deletion of user-owned links

Talk track:

“I’d rate-limit creates, support disable, and avoid trivially enumerable codes if links are sensitive.”

Consistency and failure modes

• Cache stale after disable: short TTL + delete-on-disable
• DB primary down: redirects may still hit cache; creates fail closed
• Wrong 301 forever: prefer 302 if targets change

First ten minutes structure

1. Requirements + non-goals (2 min)
2. API + 301/302 choice (1 min)
3. Capacity back-of-envelope (2 min)
4. Encoding + schema (2 min)
5. Hot path + cache (2 min)
6. Scale-out / abuse if time (1 min)

Tradeoffs to keep ready

• Deterministic hash vs random codes
• 301 vs 302
• Sync vs async analytics
• SQL vs wide-column (SQL is fine until proven otherwise)
• Exact click counts vs sampled

Soft practice note

URL shortener rounds are narration plus clean diagrams. If you want a Chrome side panel to rehearse this system design URL shortener talk track under timed pressure, Luna Interview is built for calm rehearsal. Use it to build structured communication—not to invent production war stories or to violate interview rules.

Day-of checklist

• [ ] Assumptions written (R/W ratio, custom alias, TTL)
• [ ] APIs named including redirect status code
• [ ] Capacity estimate spoken with units
• [ ] Short-code strategy + length justified
• [ ] Schema with PK on short code
• [ ] Cache on redirect path + invalidation
• [ ] Abuse/rate-limit mentioned
• [ ] One scale-out sentence ready

Keep the redirect path boring and fast—that is the URL shortener interview talk track.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.