URL Shortener

I built a URL shortener on one server and ran nine scripted events against it: more traffic, new requirements, and failures. When an event broke the design, I changed it only enough to pass. The final version handles about 877 million redirects a month at a 14.8 ms p99, with no errors, for €9.56 a month.

TypeScript · Node.js · SQLite · nginx · Litestream · Linux · Bash · k6 · Python

Code and raw resultsScoreboard

What a URL shortener does

You paste a long link and get a short one, like bit.ly/FXsk. Anyone who opens the short link is sent to the long one. Short links are used where long ones don’t fit or are hard to type: social posts, text messages, printed material and QR codes. The service also counts clicks, which is often the reason a company uses one.

It is a common system design question because it is easy to state but touches most of the core topics: generating unique IDs, a read-heavy workload, popular keys, counting writes cheaply, durability, and recovering from failure.

Requirements

Functional, with the event that introduces each one:

• Create a short link for any http or https URL up to 2,048 characters; the code is at most 7 letters and digits. (E01)
• Redirect a short link to its URL; unknown codes get “not found”. (E01)
• Let a creator choose a custom name, with exactly one owner per name. (E03)
• Show clicks per link per day, at most 60 s behind and within 1%. (E05)
• Let an operator take a link down; it must stop redirecting within 60 s, browsers included. (E09)

Non-functional:

• Redirect p99 under 100 ms, create p99 under 300 ms, errors under 0.1%.100 ms is about where a response stops feeling instant (Nielsen). p99, not the average: at 1,000 clicks a second the slowest 1% is still 10 people every second (Dean and Barroso, The Tail at Scale).
• Power cut: no acknowledged link lost, redirects back within 5 minutes.
• Machine lost: back within 1 hour, losing at most the last 5 minutes of new links. In interview terms, an RTO of 1 hour and an RPO of 5 minutes.

The numbers

Scale is measured against Bitly, which reports over 100 billion clicks and 2 billion new links a year.bitly.com/pages/about, checked 1 October 2026. The target here is 10% of that.

The system is sized for the peak, because that is when it breaks. Monthly totals use the average: 1,000 ÷ 3 ≈ 333 redirects a second, over the 2,629,800 seconds in a month.

Two traffic details matter more than they look. Clicks follow a Zipf distribution, so a few links get most of them. And every click opens a new HTTPS connection, because short links are mostly clicked once by different people. That second detail turned out to drive most of the CPU cost.

How long the codes need to be

Each character of a code is a letter or a digit: 26 + 26 + 10 = 62 options. So a code of n characters has 62ⁿ possible values. Dividing by the 17.5 million links created a month shows how long each length lasts:

The requirement allows 7 characters, so codes never run out. Because codes count up from 1, they also stay as short as possible: link 10,000,000 is FXsk.

API and data model

• POST /links with {"url": …, "name": …} → 201 and the short link; 409 if the name is taken.
• GET /<code> → 301 to the URL, with Cache-Control: no-store; 404 unknown; 410 taken down.
• GET /links/<code>/stats → clicks per day.
• POST /links/<code>/takedown with an operator secret.

Three tables: links(id, url, created_at, taken_down_at), names(name, url, created_at, taken_down_at), and clicks(code, day, count). A generated code is the link’s row number written in base 62. Custom names must contain a hyphen or be longer than 7 characters, so they can never collide with a generated code.

Event by event

The nine events were fixed before anything was built and never changed afterwards. Each one runs against the current version. If it passes, nothing changes. If it fails, the smallest fix that passes becomes the next version, and every earlier event is rerun on it. The diagram beside each event shows the version that passed it, with what that version added in red.

What was measured, and what it caught

Every run recorded what users feel and what each resource was doing, once a second. A break was diagnosed only when a measurement named the resource that ran out.

What users feel

Which resource ran out

The final design

• One server with 4 vCPUs and 8 GB of memory.
• nginx terminates TLS and passes requests to one Node.js program on the same machine.
• SQLite in one file: WAL mode, synchronous = EXTRA.
• Click counts kept in memory and saved once a second.
• Litestream copies every change to a separate volume; a script rebuilds on a new server with the same IP.
• An external monitor checks /health every 30 s.

⊕Monthly cost€4-vCPU server8.49IPv4 address0.5010 GB volume for the copy0.57Monitoring0.00Total9.56Hetzner prices, excluding VAT, checked 3 and 5 October 2026.At the largest run, 1,000 redirects a second with peak traffic assumed to be three times the average:

1,000 redirects/s ÷ 3 × 2,629,800 s/month ≈ 877 million redirects/month

What runs out next is CPU. In the largest run it averaged about 50%: nginx used about one core for TLS, and Litestream up to one and a half while rewriting its copy.

Caveats

• One event at a time. Combinations, like a viral spike during a power cut, were never tested.
• Failures at a smaller scale. The power cut and the machine loss ran at 1% of Bitly’s traffic with 10 million links. At 100 million links, restoring alone takes about 3 minutes.
• Measured next door. The load generator sat in the same data centre, so the times don’t include visitors’ own internet connection.
• One machine, one data centre. The copy lives in the same location, so losing the whole data centre isn’t covered.
• No domain. Links used the server’s IP address and a self-made certificate. A real service needs a domain and a proper certificate.
• An assumed peak factor. The monthly figure assumes peak traffic is three times the average. Only the 1,000 redirects/s peak was measured, and no capacity above it is claimed.
• Slow hosts. On some Hetzner hosts about 1.5% of new TCP connections took an extra 50–60 ms to open, putting redirect p99 near 100–118 ms in two of three machine-loss runs. The server’s own response stayed about 3 ms.

What this taught me about system design

1. Start simple and add parts on evidence. One process and one SQLite file served 100 million links at 1,000 redirects a second with a p99 around 15 ms.
2. Find the real bottleneck before adding parts. It was TLS handshakes from new connections, not the database. nginx was added for TLS on more cores, not for load balancing.
3. Batch frequent small writes. Saving per click collapsed at 166 a second; saving once a second counted over a million clicks exactly at 2,000 a second.
4. Know what “saved” means. A database default can roll back a write it already confirmed. Decide what an acknowledgement promises, then test it by pulling the plug.
5. A counter is a fine ID generator. It is unique by construction. Its one risk, reusing codes after a restore, is closed by jumping ahead. No separate key service needed.
6. Every cache has a cost. A cache or CDN would have broken click counting and made takedowns slow. Without one, takedowns work from the next click.
7. Set recovery targets first. An RTO of 1 hour and an RPO of 5 minutes were met with a continuous copy and a rebuild script, for 57 cents a month.
8. Watch p99, not averages. The 30-second freeze and the slow connections only showed up in the tail.

What usual designs add, and when you’d need it

The usual interview answer for a URL shortener includes the components below. None were needed for these requirements. Each one would be needed if the requirements changed.