System requirements

Functional:

1. given a normal url, covert and return a shorten url
2. give a shorten url, redirect to the normal url.

Non-Functional:

High availability

Low latency

prevention from the attackers

stats like the url clicks ratio per shorten url

Capacity estimation

Assume:

200 requests per second for creating short urls

20, 000 requests per second for viewing short urls (redirecting short URL to long URLs)

Store 1 year data

Storage to save 1 year's data:

1 year: 200 * 60 * 60 * 24 * 365 ~ 6 Billion urls to generate. Assume the short url only contains A-Za-z0-9. So a string with 6 chars should be sufficient as 6^65 > 65 Millions. Assume the long url length is 100 Bytes on average. So the total disk space for 1 year's data is (100 + 6) * 6 Billion ~ 636GB. So at the disk level, capacity/scaling is not a concern.

Cache

Assume average lifetime of a shorten url is 30 days.

So total number of alive urls ~ 200 * 10^5 * 30 = 600 million. The total size is about 50GB. Easy to fit into the redis on a normal machine

API design

api to create a shorten url:

POST: https://tinyurl.com/api/create

Return: a generated shorten url

api to redirect to normal url from shorten url

GET: https://tinyurl.com/{short_url}

Return: redirect to the normal url

Database design

a normal SQL database. A table called shortURL with the following columns:

shortenurl: shorten url with 6 character long

normalUrl: normal url

createdTimestamp: time

High-level design

has a loadbalancer to distribute the traffic

stateless API service could scale out easily

cache helps to improve the response time and reduce the workload overhead from database

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Generate logic:

We could use a MD5 to hash the normal url. And we only take the first 6 characters. Then check with DB if the shorten url exists. If not, we save it to the DB and return to the users. If it exists, we could take the next 6 characters, repeat the previous step, until we find the one.

Trade offs/Tech choices

Failure scenarios/bottlenecks

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

Future improvements

If we want to enable auth, we could add an auth micro service.

Introduce Message Broker like Kafka, so other services could consume the data like url click for further process (data aggregation)