Designing a High‑Performance Short URL System

Introduction

Designing a high‑performance short‑link system may look simple, but each component can be expanded into many technical topics, making it an excellent interview design question. The article shares the architecture and ideas behind a production‑grade short‑link service that has been stable for over two years.

Why Use Short URLs?

Short URLs save characters on platforms with length limits (e.g., Weibo, SMS), improve visual layout, generate cleaner QR codes, and are more reliably recognized as hyperlinks on some apps.

Basic Redirection Principle

A short URL returns an HTTP 302 response with a Location header pointing to the long URL; the browser then follows the redirect. 302 (temporary redirect) is preferred over 301 (permanent) because it allows the server to count each click.

Short‑Link Generation Methods

1. Hash‑Based Algorithm

The long URL is hashed (e.g., using Google’s non‑cryptographic MurmurHash ) to produce a 32‑bit value, which is then encoded in base‑62 to obtain a compact string (e.g., 3hcCxy ). The mapping between short and long URLs is stored in a MySQL table:

CREATE TABLE `short_url_map` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `lurl` varchar(160) DEFAULT NULL COMMENT '长地址',
  `surl` varchar(10) DEFAULT NULL COMMENT '短地址',
  `gmt_create` int(11) DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Collision handling relies on a unique index on surl ; on conflict the long URL is modified (e.g., appending a custom token) and re‑hashed. Bloom filters can further reduce DB lookups.

2. Auto‑Increment ID Algorithm

Four common ID sources are discussed:

UUID – globally unique but long and unordered, causing index fragmentation.

Redis – fast, but requires persistence and high‑availability setup.

Snowflake – time‑based, but clock skew can cause conflicts.

MySQL auto‑increment – simple; to avoid write bottlenecks, a pre‑allocation table ( url_sender_num ) reserves ID ranges for each machine, allowing local generation without frequent DB writes.

The final mapping table stores id , the original long URL, its MD5 hash (for a smaller index), and creation time:

CREATE TABLE `short_url_map` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '短链 id',
  `lurl` varchar(10) DEFAULT NULL COMMENT '长链',
  `md5` char(32) DEFAULT NULL COMMENT '长链md5',
  `gmt_create` int(11) DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

High‑Performance Architecture

During traffic spikes (e.g., flash sales), the service uses OpenResty (Nginx + Lua) to handle >1 million QPS with a few servers. OpenResty integrates Redis caching and can directly query MySQL, eliminating an extra business‑logic layer and reducing latency.

Conclusion

The article provides multiple design options for short‑link services, including hash‑based and auto‑increment approaches, collision mitigation with Bloom filters, and a high‑throughput OpenResty deployment. Readers are encouraged to explore the mentioned technologies (Bloom filter, OpenResty, MySQL page splitting, B+‑tree internals) for deeper understanding.