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.

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{

id: long

url: varchar

alias: varchar

}

Detailed Component Design

No need for microservice architecture. 1 monolith application is enough with 2 REST urls. Can be implemented as a Java Web application

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

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

For alias, user can additionaly specify the expiration time, after which it will be removed from the database. Default: never expires.

Alias generation strategy: each ID will be generated from the table row's id (generated by the database), and then encoded as base 64. Database system will prevent collision because it will assign different IDs for different transactions.

How identifiers are created: database just increment long numbers starting from 0.

There should be automatic horizontal scaling in case of viral link: new nodes will be added to handle high read. Only reading path is affected.

Caching strategy: Lazy Loading. In case of cache miss, URL will be loaded from the database by the alias and put into the cache.

Cache eviction strategy to prevent cache bloating: TTL 24 hours

ID Generator outage should not happen because it is a part of a database system which is very reliable.