System Design Interview Question: Design URL Shortener

Designing a scalable and secure URL shortener service like TinyURL or Bitly from the ground up.

Celebrate 4th of July with 35% off on our paid subscription — limited-time offer, don’t miss out!

Hello guys, if you are preparing for System Design interview then there is a good chance that you must have come across questions like Design URL Shortener like TinyURL or Bitly.

Earlier, we have solved and discussed popular System Design questions like Design Twitter, Design WhatsApp, and Design Spotify and in this article, we will solve the URL Shortner problem, one of the most popular and oldest System design interview question I have seen.

Designing a URL Shortener is one of the most popular system design questions you will encounter in interviews, especially at companies like Google, Amazon, Meta, and other product-based firms.

The problem may look simple at first glance—after all, how complex can converting a long URL into a short one be? Just a Map right? But, as you dive deeper, you will realize it tests several key concepts like scalability, high availability, fault tolerance, consistency, and efficient storage.

A URL shortener, like bit.ly or TinyURL, takes a long URL (for example, https://www.substack.com/some/very/long/path) and converts it into a much shorter and easy-to-share URL (for example, https://bit.ly/abc123). When users click on the short URL, they are redirected to the original long URL.

During the interview, you are expected to discuss and design a system that can handle millions (or even billions) of URLs, support high throughput for both reads and writes, ensure that redirection happens in near real-time, and handle challenges such as collisions, expired links, and analytics tracking.

In this discussion, you should also consider the following:

• How to generate unique short keys efficiently?

• How to ensure the system can scale horizontally as the number of users grows?

• How to store and retrieve mappings between short URLs and original URLs quickly?

• How to handle features like link expiration, custom aliases, and analytics.

This question is a great way to demonstrate your knowledge of distributed systems, caching, databases, hashing, API design, and performance optimization. Let’s break down the design and explore various components, trade-offs, and best practices.

By the way, if you are preparing for System design interviews and want to learn System Design in a limited time then you can also checkout sites like Codemia.io, ByteByteGo, Design Guru, Exponent, Educative and Udemy which have many great System design courses. These will help you prepare better.

While answering System design questions like this you can also follow a System design template like this from DesignGurus.io to articulate your answer better in a limited time.

For this article, I have teamed up with Hayk, a System design expert, and author of how Payment System Works and he will explain you step by step how to solve this System Design interview question and with this, over to Hayk to take you over rest of the article.

This is a system design interview question, which is to design a URL shortener tool like TinyURL or Bitly from the ground up.

We'll cover everything from design requirements, architecture, and component design to scaling for high-performance and security best practices.

Defining the Scope: Functional and Non-functional Requirements

First, we need to define this system's functional and non-functional requirements.

We have two functional requirements:

1. When given a long URL, we have to create a short URL

2. When given a short URL, we must redirect the user to the long URL.

The non-functional requirements for our service are to prioritize low latency (fast responses) and high availability (always online).

Clarifying Questions for the Interviewer

Here are some clarifying questions that we might ask the interviewer to ensure we're aligned on the system's scale:

• Usage: Estimate the number of URLs we'll need to create each second (let's say it's 1000).

• Characters: Can we use numbers and letters (alphanumeric) or other symbols? (We'll assume alphanumeric characters).

• Uniqueness: Do we generate a unique short URL each time, even if multiple users submit the same long URL? (For this design, we will).

Estimation: Data Math

With this information, we need to calculate how long the URL should be after shortening. Of course, we're trying to make it as short as possible, but we need to keep in mind the number of created URLs each year.

First, let's estimate the number of unique URLs needed for a significant period. A common approach is to plan for at least a few years of operation. For simplicity, let's calculate for 10 years.

• Seconds in a Year: Seconds in a year: 60 seconds/minute × 60 minutes/hour × 24 hours/day × 365 days/year = 31.536 million seconds

• Total Seconds in 10 Years: 31.536 million × 10= 315.36 million seconds

• Total URLs in 10 Years: 1,000 × 315.36 million = 315.36 billion unique URLs

This means our database will handle 1000 writes per second and every year, we will have 1000 × 60 × 60 × 24 × 365 = 31.5B URLs created.

If we assume that we will typically have 10x more reads than writes, that means that we'll be getting more than 10 × 1000 = 10000 reads per second.

Now, we need to figure out how many characters will give us enough unique short URLs for our 10-year volume. Given that the character set size is 62, the length of the URL identifier can be calculated as follows:

• 62¹ = 62 unique URLs (1 character)

• 62² = 3844 unique URLs (2 characters)

• …and so on.

Continuing this calculation, we see that 62⁷ (around 3.5 trillion) is the first value larger than our projected 315 billion URLs needed.

Therefore, to support our projected growth over the next ten years, our shortened URLs need a minimum of 7 characters.

High-Level Architecture

Our system will have these key components:

Users: We will have users who send their long URLs to be shortened or who send us a short URL, and we need to redirect them to the long URL.

Load Balancer: All of these requests go through a load balancer, which distributes the traffic across multiple web server instances to ensure high availability and balance of the load.

Web Servers: These server replicas are responsible for handling the incoming HTTP requests.

URL Shortener Service: We also need a URL shortener service that contains the core logic for generating short URLs, storing URL mappings, and retrieving the original URLs for redirection.

Database: Stores the connection between short URLs and their long counterparts. Before designing the database, we need to consider the potential storage requirements for our shortened URLs.

Each URL will include the unique identifier (roughly 7 bytes), the long URL (up to 100 bytes), and user metadata (estimated at 500 bytes). This means we need up to 1000 bytes per URL. Over ten years, with our projected volume, this translates to approximately 315 terabytes of data.

Before moving any further, let's first think about the API Design of our single web server.

API Design

Let's define the basic API operations for our service. As stated in our functional requirements, we will use a REST API, and we need two endpoints.

1. Create a Short URL (POST /urls)