Home>

...

>

System Design: TinyURL

System Design: TinyURL

Learn to design a scalable URL shortening service like TinyURL by defining functional and non-functional requirements, estimating capacity for high traffic, architecting a resilient, efficient system, and evaluating the design against performance, reliability, and scalability goals.

Introduction

A URLUniform Resource Locator (URL), is an address that uniquely identifies a resource on the web. shortening service creates a short alias, or short link, for a long URL. When a user clicks the short link, they are redirected to the original, longer address. The diagram below shows how this works.

How URL shortening service works
How URL shortening service works

Advantages

The main advantages of a URL shortening service are:

  • They are easier to share and type, and fit better where character counts are limited, such as in text messages or on social media.

  • They can provide a cleaner, more professional appearance in communications.

Disadvantages

URL shortening services also have some drawbacks:

  • Branding can be diluted when many companies use the same short domain name from a third-party service.

  • There is a dependency on the third-party service. If it shuts down, all associated links will break.

  • The service’s reliability and security reflect on your brand. Popular custom URLs may also be unavailable if they are already taken.

AI Powered
Saved
1 Attempts Remaining
Reset
List four building blocks required for designing TinyURL service

Several building blocks can be considered for the system design of TinyURL. Recognize these building blocks based on the following requisite functionalities in the design and provide your answer in the AI widget given below:

It’s necessary to: 

  • Store the shortened URLs.
  • Provide unique IDs for each URL.
  • Store frequent URL-related requests to serve them efficiently. 
  • Limit the number of incoming requests.



Requirements for URL shortening design

Let’s look at the functional and non-functional requirements for the service we’ll be designing:

Functional requirements

  • Short URL generation: Generate a unique short alias for a given URL.

  • Redirection: Redirect a short link to its original URL.

  • Custom short links: Allow users to create custom short links for their URLs.

  • Deletion: Allow users to delete a short link with proper authorization.

  • Update: Allow users to update the long URL associated with a short link, with proper authorization.

  • Expiry time: Assign a default expiration time for short links, but allow users to set a custom expiration.

Note: The system deletes expired short URLs after five years, even though they are not reused. Retaining them indefinitely would cause the datastore’s search index to grow continuously, which increases query time and overall latency.

Non-functional requirements

  • Availability: The system must be highly available. Any downtime will cause URL redirections to fail. This requires significant fault tolerance, as the service’s domain is part of every generated URL.

  • Scalability: The system must scale horizontally to handle increasing traffic.

  • Readability: Generated short links must be easy to read and type.

  • Latency: Redirection must happen with very low latency for a good user experience.

  • Unpredictability: Generated short URLs should not be guessable. Using sequential IDs would create a security risk, allowing others to find and access links.

Note: Predictable short URLs create a security risk because attackers can identify patterns and attempt to guess private links. To mitigate this risk, the system avoids sequential IDs. Instead, it generates random identifiers. This approach produces unique short URLs that are difficult to predict.

Functional and non-functional requirements
Functional and non-functional requirements

Resource estimation

Before designing the system, we need to estimate the required resources. These estimations are based on the following assumptions.

Assumptions

  • The ratio of shortening requests (writes) to redirection requests (reads) is 1:100.

  • The system handles 200 million new URL shortening requests per month.

  • A URL shortening entry requires 500 bytes of storage.

  • Each entry expires after five years unless explicitly deleted.

  • The service has 100 million daily active users (DAU).

Storage estimation

With 200 million new entries per month stored for 5 years, the total will be 12 billion.

200 Million/month×12 months/year×5 years=12 Billion URL shortening requests200\ \text{Million/month} \times 12\ \text{months/year} \times 5\ \text{years} = 12\ \text{Billion URL shortening requests}

At 500 Bytes per entry, the total storage required is 6 TB:12 Billion×500 Bytes=6 TB12\ \text{Billion} \times 500\ \text{Bytes} = 6\ \text{TB}

URL Shortening Service Storage Estimation Calculator

URL shortening per month200Million
Expiration time5Years
URL object size500Bytes
Total number of requestsf12Billion
Total storagef6TB
Total storage required by the URL shortening service in 5 years
Total storage required by the URL shortening service in 5 years

Query rate estimation

With a 1:100 write-to-read ratio, 200 million new URLs per month will result in 20 billion redirection requests.

200 Million×100=20 Billion200\ \text{Million} \times 100 = 20\ \text{Billion}

To calculate the Queries Per Second (QPS), we first find the number of seconds in an average month (30.42 days):

30.42 days×24 hours×60 minutes×60 seconds=2628288 seconds30.42\ \text{days} \times 24\ \text{hours} \times 60\ \text{minutes} \times 60\ \text{seconds} = 2628288\ \text{seconds}

This gives us the following rates:

  • Write QPS (new URLs per second):200 Million2628288 seconds=76 URLs/s\frac{200\ \text{Million}}{2628288\ \text{seconds}} = 76\ \text{URLs/s}

  • Read QPS (redirections per second):100×76 URLs/s=7.6 K URLs/s100 \times 76\ \text{URLs/s} = 7.6\ \text{K URLs/s}

Bandwidth estimation

Shortening requests (writes): For 76 new URLs per second, the total incoming data is:

76×500 Bytes×8 bits=304 Kbps76 \times 500\ \text{Bytes} \times 8\ \text{bits} = 304\ \text{Kbps}

Redirection requests (reads): For 7.6K redirections per second, the total outgoing data is:

...