Requirements

Functional Requirements:

1. Add a new URL (like https://www.youtube.com/) and generate a short alias for it
2. When requesting alias, redirect to the URL

Non-Functional Requirements:

1. Availability 99.9% for alias creation, 99.99% for alias retrieval
2. Adding new url should be below 200 ms at p99
3. Redirecting should be below 50 ms at p99
4. System must scale horizontally (for reading) to absorb viral links
5. System must handle concurrent alias additions
6. System will be stateless

Capacity Estimation

Daily users: 1 million / day

Storage capacity: 1 url = 50 bytes average

1000 new urls a day = 50kb per day, 1.5 mb per month, lets say 100 mb per 5 years shall suffice

API Design

POST /alias [URL] -> {url: "http://url123", alias: "abcd"}

GET /alias/abcd -> {url: "http://url123", alias: "abcd"}

High-Level Design

Only 3 components are required: Load balancer to distribute requests among instances, server instance, and a database.

No need to worry about concurrency because the server be stateless.

Write path: client sends url -> url is verified as well-formed -> alias generated (next unique integer to base64) -> added to db -> returned to client

Read path: client sends alias -> url is retrieved from cache or DB -> returned

Caching can be done on Local Cache, no need to add distributed cache

Database Design

SQL will be a good solution because our data is a relation by nature (relates URL and its alias), very natural

table alias{

url: varchar

alias: varchar

}

Detailed Component Design

No need for microservice architecture

1 monolith application is enough: 2 REST urls