Design and Implementation of a Short URL Service: Principles, Storage, and High‑Concurrency Strategies

Short URLs are commonly seen in spam SMS because they save character space, look cleaner, enable click‑through statistics, and hide query parameters, making them ideal for platforms with length limits.

The basic workflow of a short‑URL service includes four steps: (1) a service maps a long URL to a short one (e.g., www.baidu.com -> www.t.cn/1 ); (2) the short URL is embedded in messages; (3) the user clicks the short URL, triggering a 301/302 redirect to the original long URL; and (4) the target content is displayed.

This article focuses on the first step—how to generate a short URL from a long URL.

Service Design

Ideally, an algorithm would uniquely convert each long URL to a short URL and allow reverse lookup, but such a perfect compression is impossible. The practical approach is to use an ID generator: each new long URL receives an incrementing number, which is then encoded (often in base‑32) to form the short URL. For example, the first URL might become www.x.cn/0 , the second www.x.cn/1 .

How to Store the Mapping?

The mapping must be persisted to survive restarts; a relational database such as MySQL can store the long‑URL/short‑URL pairs, using an auto‑increment primary key for simple ID generation when traffic is low.

Ensuring One‑to‑One Mapping

Using a simple incrementing ID does not guarantee that the same long URL always receives the same short URL; repeated submissions produce different short URLs. Achieving strict one‑to‑one mapping would require additional storage (e.g., a key‑value store) to cache recent or popular mappings, trading off space for faster lookups.

Short URL Storage Format

Short URLs are often represented by converting the numeric ID to a higher base (e.g., base‑32) to reduce length. Internally, storing the numeric ID in decimal is more space‑efficient and simplifies range queries, while conversion to other bases can be performed on demand.

High Concurrency

Directly writing each new ID to MySQL can become a bottleneck under high load. Common optimizations include:

Cache: Keep frequently accessed long‑URL/short‑URL pairs in memory or a fast cache like Redis to avoid database hits.

Batch Allocation: Retrieve a block of IDs (e.g., 10,000) from the database at once, serve them from memory, and write back the used range in bulk when the block is exhausted, reducing the number of database round‑trips.

Distributed Architecture

A single ID generator is a single point of failure. A distributed approach can allocate distinct ID ranges to multiple generator instances (e.g., each service handles numbers ending with 0‑999 and increments by 1000). This eliminates inter‑service coordination while still providing unique short URLs.

By combining persistent storage, caching, batch ID allocation, and a distributed generator design, a short‑URL service can handle high request volumes reliably.