System requirements

Functional:

-first api (POST): has a text box, after user enter a link then return a short link on screen

-second api (GET): if the user enter the short link on browser, api return and redirect the original link

Non-Functional:

• Scalability: server can scale with high traffic (using Kubernete)
• Performance: should return data with minimal latency (consider using distributed server) (caching by Redis)
• Reliability: zero down time, no loss data (distributed server)
• Storage: can handle big data
• backup and recovery: should has back up and auto recover when there are server incident or natural disaster by using database replicated across regions.
• Maintainability: easy to maintain, implement some generic model like MVC, Clean architect
• Security: Basic requirement like Https, user authentication by Oauth2. Has rate limiting to avoid abuse or spam or DDOS.

Capacity estimation

Let assume that we will have

link

Storage:

Table User

-ID: 8 bytes

-username: 32 bytes

-password: 64 bytes

-created date: 8 bytes

-updated data: 8 bytes

=> 100k users => 12000000 => 12MB

Table Link:

-Alias: 8 bytes

-originallink: 128 bytes

=> 136 * 86400 * 365 bytes=> 430 GB per years

API design

-POST /new (to create new link)

body: {

link: string

}

response:

{

success: boolean

alias: string

}

-GET /{alias} => redirect to original link

Database design

• Table 1: ShortURLs
  • id (Primary Key)
  • alias
  • original_url
  • created_at
  • expiration_date
  • access_count

• Table 2: User
  • user_id (Primary Key)
  • name
  • email
  • password
  • Created_at

High-level design

Client:

-A website that allow user to login, register

-Has a text box for user to pass their link and receive short url

Load balancer:

-Could use Nginx, Kong to load balancing for whole system

Server:

-Use to check if the url is exist or not then query the data from database or caching service

Database:

-Store the User and Short link data

Redis:

-store the short link that already query by get method to reduce work load for the server

Request flows

Consider sequence diagrams

Detailed component design

-Client: using reactJS or react native for mobile application to have high speed development.

-Load balancer: should handle rate limiting

-Server: Consider using node JS to simplify deployment flow, easy to maintain

-Caching service: using redis

-Database: using key-value database like DynamoDB or some non SQL database like MongoDB

-Cleaning service: consider using some cron job service to clean up expired url or inactive user

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

-Sever is down and cannot return the original link to the user: should use horizontal-scale server strategy like kubernetes to avoid zero downtime.

-Server over-flow in peak time: using auto scaling like kubernete and circle breaker t

-Database is down: should use database cluster or replica read data to avoid database down

Future improvements

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