Design a URL shortener

Turn https://example.com/a/very/long/path?with=parameters into sho.rt/x7Kp2Q, and send anyone who opens the short link to the long one, quickly, for years. It's the classic first design: small enough to finish, but with real depth in generating codes, serving a flood of reads, counting clicks without slowing anything down, and keeping printed links alive. It follows the interview framework phase by phase.

1. The prompt

"Design a URL shortener like bit.ly or TinyURL. Users paste a long URL and get a short one; anyone opening the short URL is sent to the original. Link owners want to see how often their links are clicked."

The write side is tiny, and the read side is a flood that must never break, because short links end up printed on posters, packaging and business cards. Most of the interview is about the redirect path: how codes are made, how redirects stay fast and available, and how analytics stay out of the way.

2. Frame the problem

Ask these first. Each answer changes something specific; guess before you open them.

3. What it must do

1. A user can create a short link for a long URL, optionally with a custom alias and an expiry date.
2. Anyone opening a short link is redirected to the long URL.
3. The owner can see click counts for their links.

Not now:

• Editing a link's destination: it would break caching assumptions; add it later with versioned cache keys.
• QR codes: rendering only, no design impact.
• Teams, billing and accounts management: standard product plumbing.
• A/B routing: a different product.

4. How well it must do it

5. Numbers that change the design

6. The nouns

• Link: a short code and the URL it points to.
• User: the owner.
• Click: one redirect, as an event.
• Daily count: clicks aggregated per link per day, for the stats page.

links        code (primary key), long_url, owner_id, created_at, expires_at, status (active | disabled)
click events code, time, referrer, country             (a stream, not a table updated per click)
click_counts code, day, clicks                          (written by the aggregation job)

7. The contract

REST. The owner comes from the auth token. The redirect is a plain HTTP GET on the short domain, because that's what browsers do.

POST /v1/links                 Idempotency-Key: …     {long_url, custom_alias?, expires_at?}
  → 201 {code: "x7Kp2Q", short_url: "https://sho.rt/x7Kp2Q"}     (409 if the alias is taken)
GET  /{code}                   → 302 Found, Location: https://example.com/a/very/long/path…
                                 (404 if unknown, 410 Gone if expired or disabled)
GET  /v1/links/{code}/stats    → {clicks_total, clicks_by_day: [...]}          (owner only)

8. First working version

Stateless app servers behind a load balancer and one database. Build each request, then note what will break.

8.1 Creating a link

For the first version, generate 7 random base62 characters and insert with the code as the primary key; if the insert fails because the code exists, generate another. A custom alias uses the same insert, and the primary key rejects one that's taken.

8.2 Redirecting

Look the code up by primary key, check status and expiry, and answer 302 with the long URL in Location.

8.3 Counting clicks (version one)

To start, each redirect also runs UPDATE click_counts SET clicks = clicks + 1 WHERE code = ? AND day = ?, and the stats page reads those rows.

9. Make it hold up

9.1 Generating unique short codes never shared · not enumerable

Try both calculators in section 13: how long codes last, and what a scrambled counter looks like.

9.2 Redirects in under 50 ms, at 12,000 a second fast · always work

Keep the create path and the redirect path as separate services. They have different traffic, different scaling and different failure tolerance, and the redirect service should have no dependency it doesn't absolutely need.

9.3 301 or 302? fast · analytics

A 301 Moved Permanently lets browsers and proxies cache the redirect, so repeat visits never reach you: less load, but you can't count those clicks or block the link later for people who already have it cached. A 302 Found (or 307) is checked each time: you see every click, at the cost of more traffic. Shorteners that sell analytics use 302, with a short Cache-Control lifetime so CDNs can still absorb spikes. Say which you chose and why.

9.4 Counting clicks without slowing redirects fast · analytics

Clicks answered at the CDN edge never reach the origin; count them from CDN logs, merged into the same pipeline.

9.5 Aliases, expiry and abuse never shared · security

• Custom aliases go in the same table; the primary key on code rejects duplicates atomically (a conditional insert, Module 17). Reserve words like api and login, and keep aliases out of the generated-code space (for example, require a character generated codes never use, such as -).
• Expiry: check expires_at on every read (return 410); a background job deletes expired rows in batches and evicts them from the cache.
• Abuse: rate-limit creation per user and IP (Design D02), check new URLs against threat lists asynchronously, and be able to disable a code everywhere within a minute: mark it in the database, delete it from Redis, and purge it from the CDN.

9.6 Keeping printed links alive across regions always work · never lost

• Reads everywhere: serve redirects from every region, with a regional cache and a read replica (or a multi-region key-value table) in each. A region outage only moves traffic.
• Writes in one place, or blocks per region: creation is rare, so it can stay in one primary region with failover. Or each region leases its own counter blocks, so codes stay unique without cross-region coordination.
• Backups and the domain: point-in-time backups of the links table, tested restores, and the short domain itself registered with auto-renew and careful DNS. A lapsed domain breaks every link at once.

9.7 The whole design after the deep dives

Both paths through the final design: creating a link with a leased counter block, and redirecting through the edge, the cache and the database, with the click going to analytics.

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Leased counter blocks instead of random codes (no collisions; the predictability is fixed by scrambling).
• 302 over 301 (analytics and blocking over traffic).
• Asynchronous analytics (fast redirects, counts a minute behind).
• Separate create and redirect services.

What we'd watch:

• Redirect latency p99 and error rate per region.
• Cache hit rate at the CDN and Redis.
• Creation rate per user (abuse).
• Analytics consumer lag.

At 10×:

• Partition the links table.
• Counter blocks per region.
• More edge serving.

Common mistakes:

• Hashing the URL and truncating it.
• Reading the database on every redirect.
• Counting clicks with a synchronous write.
• Choosing 301 without noticing it hides clicks.
• Forgetting abuse and expiry.
• Sharding a 3 TB table on day one.

13. Try it, check yourself, read more

How long do codes last?

Encode a counter value