[ Case Study] Design a URL Shortening service like TinyURL

This document is a system design of a URL shortening service for interview preparation. Steps in this document are following The complete guide to crack the System Design interview.

All images in this document use ZenUML plugins.

URL shortening is to create shorter aliases for long URLs for better sharing, displaying and messaging.

For example, given URL of this document,

https://zenuml.atlassian.net/wiki/spaces/ZEN/pages/927334401/Case+Study+Design+a+URL+Shortening+service+like+TinyURL

A shortened URL created by TinyURL is:

https://tinyurl.com/y4peeng8

1. Requirement

Functional Requirement

Access a shortened URL

When users access to a short link, the service should redirect them to the original link if the short link is a correct one.

Generate a shortened URL

Given any URL, the service should be able to generate a unique shortened URL, and short enough to be easily copied and share.

Links will expire after a default timespan.

Non-Functional Requirement

  1. High availability

  2. Consistency: eventual consistency

  3. Latency: minimise latency when redirecting URLs

  4. Reliability: No data loss

  5. Others:

    • shortened links should not be predictable

2. Storage Estimation

Data Storage

Assumptions:

  • every shortened URL will be stored for 5 years

  • storage object will contain original url and shortened url, about 1,024 bytes

  • Storage:

    • 1 million new URLs/month: 1 million * 12 * 5 * 1,024 bytes => 62 GB

    • 10 million new URLs/month: 10 million * 12 * 5 * 1,024 bytes => 620 GB

    • 100 million new URLs/month: 100 million * 12 * 5 * 1,024 bytes => 6.2 TB

Read Write ratio

This service will be read-heavy and assume read writer ratio as 100:1.

Number of requests to service

  • 1 million new URLs/month:

    • read: 100 * 1 million = 100 million

    • for writing: 1 million / (3600 * 24 * 30) => 0.39 URLs/s

    • for reading: 100 * 0.39 = 39 URLs/s

  • 10 million new URLs/month:

    • read: 100* 10 million = 1 billion

    • for writing: 10 million / (3600 * 24 * 30) => 3.9 URLs/s

    • for reading: 100 * 3.9 = 390 URLs/s

  • 100 million new URLs/month:

    • read: 100 * 100 million = 10 billion

    • for writing: 100 million / (3600 * 24 * 30) => 39 URLs/s

    • for reading: 100 * 39 = 3900 URLs/s