Link shortener — a full worked answer

Assumptions, said in one breath: global users, a few hundred million links total, reads massively outnumber writes, auth exists but is not what we are designing, and links are permanent unless someone deletes one.

One question that changes a box: can users pick their own short code? If yes, I need a uniqueness check on a user-supplied string on the write path, which is a different write design from generating a code myself. I will assume yes, custom codes are supported, because most real products offer them and it is the more interesting version.

A second question: does the click count need to be exact, or is close enough fine? Exact means a synchronous write on every redirect, which is what I least want on that path. I will assume approximate is fine.

Scope I propose: create a link, optionally with a custom code; follow a link; and rough click counts. Out of scope: editing links, expiry, link previews, and spam and malware checking. I would flag that last one as a production requirement I am setting aside on purpose.

Actors: the creator, the visitor who clicks, and the system itself. The system is the one worth naming. It generates codes, decides whether a code is available, decides what to do with a code that does not exist, and decides which clicks count as real rather than bots.

The chain: link requested → code chosen (generated or claimed) → link stored → link served, over and over → optionally deleted or expired.

The failure branches are where the design lives. At code chosen: the generated code collides with an existing one, so retry with a new code; if it was a custom code, return "that name is taken" immediately. At stored: the write succeeds but the cache is not updated, so the first click on a new link misses. That is acceptable, because it falls through to the database. At served: the code does not exist, so return a clean 404 rather than a redirect to nowhere. Or the code exists but the destination is now dead. We cannot fix that, but we should not hide it either. At served, second branch: the destination is reported as malware after creation. We need to disable a live link and have that take effect fast, so the cache TTL is also a safety control, not only a performance one.

One more the system owns: the click that arrives while the counting queue is backed up. It should still redirect. Counting is allowed to fail; redirecting is not.

Assume 100 million new links a month. That is roughly 3.3 million a day. A day is 86,400 seconds (round it to 100,000), so about 40 writes per second. Peak at 3x is 120. One modest database handles that easily.

Reads: assume 100 clicks per link over its life, which gives about 4,000 reads per second average, call it 12,000 at peak. Also not enormous, but it is a hundred times the write rate, and that ratio drives the design.

Storage: a row is roughly a 7-character code, a URL averaging 100 bytes, a user id, a timestamp, a flag. Call it 200 bytes with overhead. 100 million a month is 20 GB a month, 240 GB a year. After five years that is about 1.2 TB, which fits on one machine. So this is not a storage problem either.

So the hard part here is read latency, not throughput and not size. Everything I build should be aimed at answering a redirect from memory. The second hard part is code generation without collisions, because that is where correctness can break.

Read path: client → CDN or edge → redirect service → cache → database, with the cache expected to answer almost everything. Justification per box: the edge is there because clicks come from everywhere and a cross-region round trip is 150 ms, which is most of my latency budget. The cache is there because 4,000 reads a second against 40 writes a second means the same links are requested again and again, and the data is tiny. The database is there because the cache is not durable.

Write path: client → creation service → database, synchronously, then a cache write. At 40 writes a second I do not need anything clever, and the user creating a link can wait 200 ms for a proper uniqueness check.

Code generation is the main decision. Three options. Hash the URL and take the first 7 characters: same URL gives the same code, which is nice, but collisions must still be handled and two users cannot get different links to the same destination. Random 7 characters from a 62-character alphabet: 62^7 is about 3.5 trillion possibilities. Even after five years (6 billion links) a new code collides less than 0.2% of the time, so insert with a unique constraint and retry on failure. That is simple and correct. Or a counter encoded in base62: no collisions at all by construction, but a single global counter is a coordination point, and sequential codes are guessable, which leaks how many links exist and lets someone enumerate them. I would take random-with-unique-constraint: the retry rate stays negligible, there is no coordination, and codes are not guessable. Cost: a tiny probability of a retry on write, which I have plenty of budget for.

Data model: one table keyed by code, holding destination, owner, created time, disabled flag. The key is the code because every read is a lookup by code. Custom codes and generated codes share the same namespace and the same unique constraint, so "that name is taken" comes for free.

Analytics: the redirect puts a click event on a queue and returns immediately. It does not wait, and it does not write to the database. A consumer aggregates counts. The Stage 1 assumption that counts can be approximate is what allows this, and it keeps the redirect path read-only.

A 301 versus 302 decision worth naming: 301 is permanent and browsers cache it, often indefinitely. Repeat clicks become free, but you cannot count them, and a changed or disabled destination does not reach browsers that already cached it. 302 keeps every click coming to you. I would use 302, because click counting and the ability to disable a bad link are both requirements, and I am accepting the extra traffic that costs.

Hard part one: keeping the redirect from waiting on a database. At 200 bytes a row, the working set of popular links fits in memory easily. Cache-aside in Redis, keyed by code, with a long TTL because links almost never change. On top of that, a small in-process cache on each redirect server for the hottest few thousand codes removes even the Redis hop for the most-clicked links. Cost: a link disabled for malware stays live for as long as the longest TTL in the stack, so I would keep the in-process TTL short (30 seconds), delete the Redis entry, and publish an invalidation message on disable. I am accepting up to 30 seconds of a bad link being live in exchange for removing a network hop from the hot path.

The empty-cache case is the one that takes services down. If Redis restarts empty, every redirect goes to the database at once: 12,000 a second at peak against a database sized for 40 writes. Two defences: coalesce misses so a thousand simultaneous requests for the same code produce one database read, and warm the cache from the top codes before taking traffic. Cost: coalescing adds a lock per key and a small latency penalty on the miss path.

A request for a code that does not exist is not cached by plain cache-aside, because there is nothing to store. So an attacker requesting random codes drives every request to the database. Cache the negative result for a short window, or put a bloom filter of existing codes in front. Cost: a newly created link may be briefly reported as missing if the filter is stale, so the filter is updated on write and the negative cache TTL is kept to seconds.

Hard part two: correctness on creation. The unique constraint on the code column is what guarantees no two links share a code. Application logic cannot, because it has a race between checking and inserting. Insert, catch the constraint violation, generate a new code, retry up to a few times. For custom codes, the same constraint gives "that name is taken" with no extra code. I also need a reserved list so nobody claims /api, /login or /settings. Cost: the reserved list must be updated every time the product adds a top-level route, and it is easy to forget.

Abuse, which an interviewer is likely to raise and which I would raise myself: this service is an excellent tool for hiding malicious destinations. Rate limit creation per account and per IP, check destinations against a reputation service asynchronously after creation, and make disabling a link fast and cache-aware. Cost: the async check means a bad link is live for a short window. I accept that, because a synchronous check would put a third-party call on the creation path and make creation fail whenever that service does.

Scaling later, said as a plan rather than a build: redirect servers are stateless so they scale horizontally behind a balancer; the database gets read replicas long before it needs partitioning; and if it ever does, the code is a good shard key because every read and every write is keyed by it. Cost of that future move: the data migration itself, but no query or data model changes, because the key was chosen on day one.