System requirements

Functional:

• Generates the shortenURL
  • if we send the rawURL it will return the shorten URL
• Get rawURL
  • if we give shorten URL it will return longURL

Non-Functional:

• Should be high availability
• Low Latency
• Strong consistency

Capacity estimation

Estimate the scale of the system you are going to design...

• DAU : 2000
• Each Query Size : 500B
• QPS (Write) : 2000 / 24 / 60
• QPS (Read) : 200000 / 24 / 60
• Storage Required : 500B * 2000 * 365 * 10 (for 10 years)

API design

Define what APIs are expected from the system...

api Endpoint :

• /api/generateURL
  • Request Body :
    • rawURL
  • Response Body :
    • shortenURL
• /api/getURL/{shorten_url}
  • Response Body :
    • rawURL

Database design

DB schema

Data

{

shortenURL: String PK

rawURL : String

Created by : Date

}

High-level design

First, client will have interaction between server (application server)

Application server will generates the hashed (shorten URL) with hashing function

check if the hashed URL existed in database -> regenerate the hashedURL, if not we can store the value (shortenURL, longURL, created by)

Request flows

First client request with rawURL with post restfulAPI call /api/generateURL -> generateURL will go to application server. Application server will generate the hashed URL and store into DB

Second client request with shortenURL with GET restfulAPI call /api/getRawURL/{shorten_url} which go to application server and look for the shortenURL database and get the value to client as response

if the value not exist -> response should give failed to get RawURL

Detailed component design

Hashing Function should work with MD5 from client IP address and time stamp and base 62 to hash the value and take first several characters (it depends on the storage requirements)

Also we can scale up the DB (RDBMS) storing the metadata to make read replica which is Read-Only DB. Also, make horizontal scaling for application server and use Load Balanacer to balancing the load.

Trade offs/Tech choices

I choose DB as RDBMS for storing MetaData -> it gives relation Database which ensure consistency compare to NoSQL which supports eventual consistency. it is hard to scale up compare to NoSQL but I use Replication for strong availability.

For cache, I will use LFU Cache, since it is useful when the situation shows there is any specific URL requested lots of time compared to others.

Failure scenarios/bottlenecks

If we hold Load Balancer on loading request, it can be single point of failure. Also, there should be syncrhonization issue between Replica (leader and follower)

Future improvements

Add Analytics for logging. We can use sharding for database (by hashedURL id) it might be easier to find the URL.