System requirements

Functional:

• End user enters a large URL and receives a short URL in return.
• URL given by the user should stored encrypted and stored in the Database.
• Communication between the public and private UPIs.

Non-Functional:

• System should have high availability.
• low latency
• Horizontal scaling and durability for large database.

Capacity estimation

• DAU - 1M. Each user performs 1 write operation and probably 10 reads at max.
• Read QPS - 1M * 10/10**5(estimated number of seconds per day) = 100
• Write QPS - 1M/10**5 = 10
• Read Peak QPS - 300
• Storage - 1M * 10b * 10 = 1GB * 365 days = 365 GB = 1.5T for 5 years.

API design

Public APIs

• post/singup
• post/singin
• post/singout
• post/given-url
• get/tiny-url

Private APIs

• post/auth
• post/encrypt-url

Database design

Based on the entities in our system we can have 2 different tables.

• user

user_id/uuid (primary-key)

email

password

username

created_at

• url

user_id/uuid (foreign-key)

url_id (primary-key)

given_url

tiny_url

created_at

High-level design

• Here CDN will give me a quick access to the website while reducing latency.
• Memcached is used as in memory database in order to look for the required url and further proceed depending on it presence.
• Lookup service is responsible to check if the url is already stored in the read replicas if not then it will move to manipulation service.
• Manipulation service will translate the long url to a smaller one by using MD5 algo.
• Once done it will be stored in write operations DB which is then further connected to 2 different read replicas.

Request flows

Same as above...

Detailed component design

• The purpose of an in memory database like Memcached is to store the tiny urls in cache for low latency read operations and also prevent read hits on the database. Using caching can always be memory dependent so to prevent that we can use LRU cache or TTL cache techniques as well.
• The Manipulation Service is responsible for changing the large url into a small one using the MD5 algorithm. We are using MD5 here since our main goal is to decrease the length of the url only and return it into 128bit/16byte data. From this data we will only use last 6 unique characters as url end characters.
• Since the application is read heavy, in order to keep the application more reliable and durable we are using read replicas just for the read purposes. For the Data base we are using unstructured Database since we only have to make idempotent operations.

Trade offs/Tech choices

• We could have used a load balancer here to handle the read heavy load of large amount of users on the site.
• Multiple servers in order to avoid bottle neck in same kind of situation and with the help of services like Zookeeper, we could have handled it.

Failure scenarios/bottlenecks

• Single point of failure with single server.
• Cache invalidation and stale data.

Future improvements

• In future we can add load balancers to the application depending on the end users number.
• Horizontal scaling of the data base can also be used in case of large number of users.
• We can also have login and signup functionalities with API gateways in order to keep the system routing and authentication in check.