System requirements

Functional:

1. Create short url
2. Redirect Url
3. Visit short URL
4. User login
5. Url management system
6. Delete short url
7. Update short url

Non-Functional:

1. Availability
2. Scalability

Capacity estimation

1. Daily active user: 100,000
2. Each user creates 5 URLs, and we are looking at 100,000 * 5 = 500,000 urls/day
3. Url accessing, assuming everyday there's about 50 visits of each URL: 500,000*50 = 2,500,000 visits/day
4. Assuming the original URL length plus shorten URL is about 200 characters, each character is about 1 byte, we are looking at 200 bytes per entry.
5. daily storage: 200 * 500,000 = 1 * 10 ^ 8 bytes/day = 10^5 MB/day = 100GB/day
6. Assuming lifetime of URLs are 90 days
7. 100GB/day * 90 = 9000 GB = 9TB
8. Assuming URL contains a-z A-Z 0-9, there's 62 options for each position, 500,000 * 90 = 45,000,000 unique URLs , the length of URL is 5. 62^5 > 45,000,000

API design

Endpoitns:

1. POST createShortUrl
2. GET getUrl
3. PUT updateUrl
4. Delete removeUrl
5. User registration
6. User login

Database design

From previous calculation we found out 5unique combinations can satisfy our requirements.

Our short URL database can have the following columns

id, shortUrl(varchar(5)), longUrl(varchar), createDatetime(datetime), updateDatetime(datetime), user(userId)

For user database

id, username(varchar), password(varchar)

High-level design

Load balancer: to distribute requests from client

service: distribute services that handle all HTTP requests

Cache: for get requests, first check cache, if short URL cannot be found in short URL then check database

Database: distributed database that handles read and write

Request flows

1. User register takes username and hashed password and check if user exists, if not register user
2. User login takes username and hashed password if combination matches redirect user to login page or fail login
3. create shorten URL, pass long URL to createShortUrl
4. update, pass long Url and shortUrl to updateUrl
5. to visit go to shortUrl and will be redirected
6. delete shortUrl, pass shortUrl and userid

Detailed component design

redirect url 301 vs 302, 301 is permanent redirect and 302 is temporary redirect. 301 is used here because we don't need to keep track of user's requests afterwards.

Trade offs/Tech choices

1. For faster writes, no SQL might be used.
2. Use distributed redis, but adds overhead if cannot find in cache

Failure scenarios/bottlenecks

1. When we use redis, expiry is needed, once similar expiry occurs, it will increase traffic to database

Future improvements

Using zookeeper, where a centralized system arranges the unique key distribution.