Home/

...

/

Requirements of TinyURL's Design

Requirements of TinyURL's Design

Understand the requirements and estimations for designing a URL shortening service.

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: Our service should be able to generate a unique shorter alias of the given URL.

  • Redirection: Given a short link, our system should be able to redirect the user to the original URL.

  • Custom short links: Users should be able to generate custom short links for their URLs using our system.

  • Deletion: Users should be able to delete a short link generated by our system, given the rights.

  • Update: Users should be able to update the long URL associated with the short link, given the proper rights.

  • Expiry time: There must be a default expiration time for the short links, but users should be able to set the expiration time based on their requirements.

Note: Even though our system doesn’t reuse expired short URLs, we still delete them after their five-year lifespan. Keeping them forever would cause the data store’s search index to grow endlessly, increasing query time and adding unwanted latency.

Non-functional requirements

  • Availability: Our system should be highly available, because even a fraction of the second downtime would result in URL redirection failures. Since our system’s domain is in URLs, we don’t have the leverage of downtime, and our design must have fault-tolerance conditions instilled in it.

  • Scalability: Our system should be horizontally scalable with increasing demand.

  • Readability: The short links generated by our system should be easily readable, distinguishable, and typeable.

  • Latency: The system should perform at low latency to provide the user with a smooth experience.

  • Unpredictability: From a security standpoint, the short links generated by our system should be highly unpredictable. This ensures that the next-in-line short URL is not serially produced, eliminating the possibility of someone guessing all the short URLs that our system has ever produced or will produce.

Note: Predictable short URLs can be a security risk; attackers might spot patterns and guess private links.
To prevent this, our system avoids sequential IDs. Instead, it generates random, unpredictable identifiers, ensuring each short URL is unique, secure, and impossible to guess.

Resource estimation

It’s better to have realistic estimations at the start. For instance, we might need to change them in the future based on the design modifications. Let’s make some assumptions to complete our estimation.

Assumptions

  • We assume that the shortening: redirection request ratio is 1:100.

  • There are 200 million new URL shortening requests per month.

  • A URL shortening entry requires 500 Bytes of database storage.

  • Each entry will have a maximum of five years of expiry time, unless explicitly deleted.

  • There are 100 million Daily Active Users (DAU).

Storage estimation

Since entries are saved for a time period of 5 years and there are a total of 200 million entries per month, the total entries will be approximately 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} ...