System DesignCachingData ModelingScalabilitysenior level

Designing a URL shortener

the question

How would you design a URL shortener like TinyURL or Bitly? Assume it must handle high redirect traffic and remain available as it scales.

what they're testing: The interviewer is probing whether you can turn a simple key lookup into a justified design across scale, latency, consistency, and failure trade-offs.

a strong answer

Use stateless creation and redirect services around a durable code-to-URL store, with a shared cache on the read path. First define creation and redirect rates, link lifetime, custom aliases, destination changes, analytics, and abuse controls. Store the code, destination, owner, and expiry, and index the mapping by code.

For code generation, encode uniquely allocated IDs in a URL-safe alphabet, or generate random codes and retry when an atomic unique constraint rejects a collision. A lookup before insert is not enough because concurrent requests can both see an unused code. Partition by code only when measurements show that one indexed store cannot meet capacity or throughput.

On redirect, read the cache, fall back to the durable store on a miss, populate the cache, and return 302 Found with a Location header. For mutable links, set a cache policy that matches the allowed staleness. Use a permanent redirect only when the mapping is intended to remain permanent and long-lived client caching is acceptable. Replicate the store across failure domains, define failover behavior, and protect it from cache stampedes. Emit a compact click event and aggregate analytics outside the redirect path. Rate-limit creation and define responses for expired, missing, and blocked links.

Where people slip

the tempting wrong answer, and what's actually true

Taking the first few characters of a hash guarantees a unique short code.
A truncated hash can collide, so the database must enforce uniqueness and the service must retry or use uniquely allocated IDs.
Checking whether a code exists before inserting it prevents duplicate codes.
Concurrent creators can both pass that check, so uniqueness must be enforced atomically by the data store.
The redirect service should synchronously update analytics before responding.
Analytics aggregation should run outside the redirect path; the handler can emit a compact event to a durable stream without waiting for aggregation.
Every short link should return a permanent redirect because it is more cacheable.
Permanent status asserts that the mapping is permanent and can enable long-lived reuse. Use a temporary redirect for mutable mappings and control freshness explicitly with cache headers.

If they push further

How would you generate codes without a central bottleneck?

Compare allocating disjoint ID ranges and encoding them with generating random codes under a unique constraint. The former coordinates range assignment; the latter trades coordination for collision retries.

What happens when one short link goes viral?

Serve the mapping from cache and prevent an expiry from sending simultaneous misses to the database with per-key request coalescing or early refresh. Also plan how the data store is protected if the cache fails.

Should submitting the same long URL return the same short code?

Treat that as a product decision. Deduplication saves mappings, while separate codes support different owners, campaigns, expirations, and analytics.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.