How to design a URL shortener

Requirements

Start every design by agreeing what the system must do and how well it must do it. Interviewers expect you to ask, not assume.

• Functional: create a short link for a long URL; redirect a short link to its long URL; optionally allow a custom alias and an expiry date.
• Functional, optional: click analytics per link (count, referrer, country).
• Non-functional: redirects must be fast - aim for a p99 under 50ms at the server - and highly available, because a broken short link breaks every page that embeds it.
• Non-functional: short codes should not be guessable in sequence if links are private, and a code must never point at two different URLs.

Capacity estimates

Use round numbers and say them out loud. The goal is the order of magnitude, which decides the architecture.

Two conclusions fall out. Writes are tiny, so the write path barely matters. Reads are 100 times larger and bursty, so the whole design is about serving redirects cheaply.

API design

Two endpoints are enough. Keep the redirect endpoint at the root so short links stay short.

POST /api/links
{ "long_url": "https://example.com/a/very/long/path", "alias": "launch", "expires_at": "2027-01-01" }
→ 201 Created
{ "code": "launch", "short_url": "https://sho.rt/launch" }

GET /{code}
→ 302 Found
Location: https://example.com/a/very/long/path

Data model

The access pattern is a single key lookup - code to URL - so the data model is one table keyed by the code. That shape fits a key-value store such as DynamoDB or Cassandra, or a relational table sharded by code.

links
  code        varchar(10)  primary key
  long_url    text
  owner_id    bigint       nullable
  created_at  timestamp
  expires_at  timestamp    nullable

Keep click events out of this table. Writing a row on every redirect would turn a read-heavy system into a write-heavy one.

Generating short codes

There are two standard approaches, and interviewers want to hear the trade-off between them.

• Counter + base62: give every link a unique integer ID and encode it in base62 (a-z, A-Z, 0-9). There are no collisions by construction. To avoid a single counter becoming a bottleneck, hand each API server a block of IDs (for example 1,000 at a time) from a coordinator, or use a Snowflake-style generator.
• Hash + truncate: hash the long URL (for example SHA-256) and keep the first 7 characters. The same URL always gets the same code, but two URLs can collide, so you must check and retry on collision.
• Sequential counters produce guessable codes. If links can be private, shuffle the ID with a reversible permutation before encoding, or add random characters.

High-level design

The write path is simple: client → load balancer → API server → ID generator → database. The read path carries almost all the traffic and is where the design is won or lost.

• Client → load balancer → API servers → cache → database. A CDN in front is optional; see the cost note below.
• The API server looks the code up in the cache first; only misses go to the database, and the result is written back to the cache.
• The database is sharded by code, so every lookup touches exactly one shard.

Where it breaks

Send redirect traffic straight from the API servers to the database and the database saturates first. In the simulation above, 3,000 redirects per second against a database that can serve 1,000 means two thirds of requests fail, and the rest wait while the database sits near 100% utilization. Adding API servers does nothing - the bottleneck is behind them.

That is the moment interviewers are waiting for: you find the bottleneck from the numbers, not from memory.

Scaling the redirect path

Redirects are idempotent and the code-to-URL mapping almost never changes, which makes them ideal for caching at every layer.

• Cache the mapping in Redis or Memcached. With a 90% hit ratio, only one redirect in ten reaches the database.
• A CDN can absorb a viral link at the edge, but it bills per request. At 20,000 redirects per second, CloudFront's list price comes to over $50,000 a month, many times the cost of the servers behind it, and a redirect is too small to save meaningful bandwidth. At sustained high traffic, cache in memory and let browsers cache 301s instead.
• Choose the redirect code deliberately: 301 (permanent) lets browsers and CDNs cache the redirect, which removes load but hides repeat clicks; 302 (temporary) sends every click back to you, which keeps analytics accurate but costs more traffic.
• Use a short TTL or explicit invalidation for links that can be edited or expire.

Analytics without slowing redirects

If the product needs click counts, record them asynchronously. The redirect handler publishes a small event to a queue (Kafka, Kinesis or SQS) and returns immediately; a separate consumer aggregates counts into an analytics store. A slow analytics pipeline can then never slow a redirect.

What interviewers look for

• You noticed the read-to-write ratio early and designed for reads.
• You can explain base62 and why 7 characters is enough.
• You put a cache in front of the database and can say what hit ratio you expect and why.
• You know the 301 versus 302 trade-off.
• You kept analytics off the critical path.