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

Server is our main service with some main functionality listed below:

• Shorten Alias: receive a long URL and then hashing with base62 (only alphabet and numeric character) and length 8 => make an unique alias present for that url
• Manage original URL: receive short link (with alias) from client, check it with caching service first. If alias is existing, return the original link to the client. If alias is not existed, query the alias from database and return it to client
• Rate limiting: although we already have rate limiting in load balancer layer. we also need implement rate limiting per user (exceptional backoff algorithm) to avoid abuse
• Scalability: use stateless design for service to easier to scale horizontally (using kubernete and docker)

Caching service: using redis to store alias and url as key-value pair

Cleaning service: work as a cron job to deactivate all expired url or inactive user. this cron job could run 1 or 2 a day

Trade offs/Tech choices

Client

-ReactJS: simple, fast development, large support community but performance is not the best

-Angular: Full-featured framework with everything included but its don't have good performance compare to the other

=> I will chose React js because this time we should aiming for fast development. We only need a simple UI so it pretty good enough

Server-Main Service:

-Node JS: simple, easy to develop, great concurrent handling but don't have good support for micro-service

-Azure Dotnet: Great supportive for micro-service but quick complicated for development and deployment

=> I will chose Node JS with the same reason i choose for Frontend side. Furthermore, both FE and BE use the same language can help team to easier to hire fullstack developer.

Database and Caching Service

-Relational database like PostgreSQL: have great performance, support indexing for fast query.

-No SQL database like MongoDB: high scale and performance, but its suitable for store document more than a simple string

-DynamoDB: highly scalable, fully managed but higher cost

-Redis: Great performance, simple, in-memory caching

=> I will chose Redis for my caching service solution and DynamoDB to store the data for better scaling performance

Microservice or monolith:

-Microservice: provide better scalability, suitable for complex system, flexibility but introduce complexity in development, deployment and harder to maintain

-Monolith: Simple, easier to learn and fast development, but harder to develop complex system.

=> I will choose monolith for our current requirements. But we can consider switching to microservice when requirements become complex.

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

-Adding analytic service to analyze user data

-Switch load balancer layer to API gateway for better management, rate limiting and authentication for api

-Split server layer to 2 separated services for shortening URL and Query URL for better scalability

-Chose better hash algorithm