# How to Design a URL Shortener: A Step-by-Step System Design Walkthrough

Arslan Ahmad

April 16th, 2026

Design a URL shortener (like TinyURL or Bit.ly) step-by-step: requirements, capacity estimation, hash generation, database schema, scaling, and common interview trade-offs.

## 1. Why do we need URL shortening?

URL shortening is used to create shorter aliases for long URLs. We call these shortened aliases “short links.” Users are redirected to the original URL when they hit these short links. Short links save a lot of space when displayed, printed, messaged, or tweeted. Additionally, users are less likely to mistype shorter URLs.

For example, if we shorten the following URL through TinyURL:

> [https://www.designgurus.io/course/grokking-the-system-design-interview](/content/course/grokking-the-system-design-interview/index.html)

We would get:

> [https://tinyurl.com/vzet59pa](https://tinyurl.com/vzet59pa)

URL shortening is used to optimize links across devices, track individual links to analyze audience, measure ad campaigns' performance, or hide affiliated original URLs.

## 2. Requirements and Goals of the System

Our URL shortening system should meet the following requirements:

**Functional Requirements:**
1. Given a URL, our service should generate a shorter and unique alias of it. This is called a short link. This link should be short enough to be easily copied and pasted into applications.
2. When users access a short link, our service should redirect them to the original link.
3. Users should optionally be able to pick a custom short link for their URL.
4. Links will expire after a standard default timespan. Users should be able to specify the expiration time.

**Non-Functional Requirements:**
1. The system should be highly available.
2. URL redirection should happen in real-time with minimal latency.
3. Shortened links should not be guessable.

**Extended Requirements:**
1. Analytics; e.g., how many times a redirection happened?
2. Our service should also be accessible through REST APIs by other services.

## 3. Capacity Estimation and Constraints

Our system will be read-heavy. There will be lots of redirection requests compared to new URL shortenings. Let’s assume a 100:1 ratio between read and write.

**Traffic estimates:**
Assuming, we will have 500M new URL shortenings per month:
- URLs shortenings per second: ~200 URLs/s
- URLs redirections per second will be: 20K/s

**Storage estimates:**
Let’s assume we store every URL shortening request for 5 years; we will need 15TB of total storage.

**Memory estimates:**
To cache 20% of these requests, we will need 170GB of memory.

## 4. Database Design

### Database Schema:

We would need two tables: one for storing information about the URL mappings and one for the user's data who created the short link.

**What kind of database should we use?** Since we anticipate storing billions of rows, a NoSQL store like DynamoDB, Cassandra or Riak is a better choice. A NoSQL choice would also be easier to scale.

## 5. Basic System Design and Algorithm

The problem we are solving here is how to generate a short and unique key for a given URL.

### a. Encoding actual URL

We can compute a unique hash (e.g., MD5 or SHA256) of the given URL. The hash can then be encoded for display.

### b. Generating keys offline

We can have a standalone Key Generation Service (KGS) that generates random six-letter strings beforehand and stores them in a database.

## 6. Data Partitioning and Replication

To scale out our DB, we need to partition it so that it can store information about billions of URLs.

### a. Range Based Partitioning

We can store URLs in separate partitions based on the hash key's first letter.

### b. Hash-Based Partitioning

In this scheme, we take a hash of the object we are storing. We then calculate which partition to use based upon the hash.

## 7. Cache

We can cache URLs that are frequently accessed using an off-the-shelf solution like Memcached. We can use 170GB of memory to cache 20% of daily traffic.

## 8. Load Balancer (LB)

We can add a Load balancing layer between Clients and Application servers.

## 9. Purging or DB cleanup

If a user-specified expiration time is reached, we can slowly remove expired links and do a lazy cleanup.

## 10. Telemetry

Some statistics worth tracking: country of the visitor, date and time of access, web page that referred the click.

## 11. Security and Permissions

We can store the permission level (public/private) with each URL in the database.

## Summary

In my experience, every successful software developer has followed a systematic approach to solve a system design question during an interview. The key to success is being organized during the system design interview.