System requirements

Functional:

Shorten URL -> Send user to original URL

Non-Functional:

Available -> if shortened URL is not working, no point of having it

Reliable -> if shortened URL doesnt bring to correct website, no point of having it

Capacity estimation

Read to write ration -> 100:1

30,000 per day, 1000 writes per day

170 bytes per row -> 17000 bytes per day -> 17 mb per day

API design

Public Endpoints:

/POST:

Receive original URL in request, and then shorten with MD5 and then 64 base encode it and store in DB

/GET:

Receive shortened URL and link to long/original URL

Database design

SQL because we have a strong relationship for all columns

MySQL

URL table:

original -> VARCHAR(150) -> 151 bytes

shortened -> VARCHAR(6) -> 7 bytes

ID -> BIGINT -> 8 bytes

High-level design

• Read heavy
• 64*6 variations of shortened URLS (base 64 encoding)
• Use MD5 Hash and then 64-base encode it

Flow:

• Request goes through API gateway
• Request goes through loadbalancer
• Sent to application server

Because it is read heavy, we could use read replicas to take pressure off the DBs

Master-Slave replicas

Request flows

Flow:

• Request goes through API gateway
• Request goes through loadbalancer
• Sent to application server
• Application creates short URL or grabs long URL, depending on GET/POST request
• Send response back to user

Detailed component design

Receive long URL, MD5 hash it, base-64 encode it, store in DB using auto increment as ID

Trade offs/Tech choices

Mysql for strong relational rows

Failure scenarios/bottlenecks

Traffic spikes during peak hours, too many reads

• to avoid this we can increase read replicas

To avoid having downtime, have multiple servers and replicas

• if a server fails, load balancer will traffic to running server while down server reboots
• if master DB is down, elect slave as leader

Future improvements

use MFU cache to cache urls that are used a lot -> redis cache

updates depending on user opinions