System requirements

Functional:

1. Client: an application, either web or mobile app to access this service.
2. Application servers, where the URL is getting transferred into a TinyURL. This service should provide options to have customized TinyURLs, and have the availability for user to login and access the TinyURL user created. This server should be connected to the metadata server, where user : tinyURL can be queried. And when type the tinyURL, this should query the actually URL from the database.
3. Database server: where the TinyURL : URL pairs are stored. This can be a relational SQL type of database for simplicity. As the data itself is quite simple. The fields are:
4. User
5. Timestamp
6. URL
7. TinyURL

Note that: we will not discuss the user login and credential service here to simplify the process. With user credentials, we can improve the service by setting access groups by user id etc.

Non-Functional:

1. Data lifespan: Lets assume we store each URL to up to 10 years.
2. This will be a heavy read system, we need to ensure the speed to access to the desired URL.
3. No duplication: Make sure there will not be duplicated TinyURLs.
4. Error handling: in times where, server is down etc, give user indicator of erroring.
5. Reliability: Data is safe and available.

Capacity estimation

Lets assume we have 500M user (5 x 10^8) and each user create 100 TinyURLs per year, each TinyURL data chunk will be:

TinyURL =>

20 Byte (User data) + 8 Byte (TinyURLkeys) + 75(URLlength) ~= 100 Byte

total storage:

5 x 10^2 * 10^8 x 10^2 = 5 x 10^12 Byte = 5TB

if we guarantee the user lifespan to be 10 years, we need to store around 50TB of TinyURL per server.

Then, for the application server, it will be a heavy read compare to write server, likely

1 write : 50 read

if we have 100M daily active user, it will result in a QPS as:

1 x 10^8 x 10^2 / 10^5 (second) = 10^5 Byte/s = 100MB/S

We will definitely need load balancing to help reduce the overhead for this, ideally between client and application server.

API design

// Generate URL

TINY_URL = SET(ORIGINAL_URL, CUSTOMIZED_URL = optional, USER_METADATA = optional)

// Query URL

GET(TINY_URL, USER_METADATA = optional)

// Change URL

MODIFY(ORIGINAL_URL, NEW_URL, USER_METADATA = optional)

// Delete URL

DELETE(TINY_URL, ORIGINAL_URL = optional, USER_METADATA = optional)

Database design

Cache: we can cache in different stages to help improve the sufficiency.

with above criteria, the database can be a simple relational database:

TinyURL | URL | TimeStamp

High-level design

Request flows

1. Client will go through the load balancer to get rerouted to the nearby/not to busy application server.
2. Application Server will determine what the requests is, either W/R/M and query the info from metadata server.
3. Metadata server should have some cache capability, and will send the corresponding data back. If not, either fetch the info from Database or generate the info and send to both Application server and database server.

Detailed component design

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?