System requirements

Functional:

1. TO create a shortened url for a given requested url
2. the urls should be unique so as to avoid loss of data

Non-Functional:

1. highly available
2. resilient enough to handle large number of requests

Capacity estimation

assume we have 30M new urls shortening per month. and we store it for lets say a year. so total capacity required will be

30M x 12 = 3.6B

API design

Should have endpoints like -

1. /shorten - will have request body of {"url":string} and response body should be {"shortened url": string, "expiry": string}
2. /redirect/{shortened url} - will return a response body of {"url": string, "found": boolean

Database design

consider average url size of 2kb

shortened url will have 17 characters so 17 bytes

created at will have 7 bytes

expiration time - 7 bytes

so total size per entry will be 2.031KB

for 30M urls per month, we need 30,000,000 x 2.031 = 60.78gb

High-level design

so we'll have a load balancer in front of our service to make sure the requests are routed correctly. A cache like Redis will be used to store the frequently accessed. for DB, we'll use noSQL like MongoDB as it is easier to scale. For increased load we can always add more clusters to make sure the system remains highly available.

Request flows

So every requests reaches the server through the load balancer. Since we need low latency and high availability, we could go for a layer 4 load balancer. load balancer redirects the request to the server. Server first tries to check in the cache for corresponding data. If there is cache miss, we can go to mongo to fetch the result. Once retrieved, cache is updated and then the response is returned to the user.

Detailed component design

Trade offs/Tech choices

We are trading off write latency for read latency. we are okay with a eventual consistent system.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

There are a lot of spof - so we deploy many laod balancers and services and cache and database clusters.

for cache failures, we'll have the data read straight from db.

for database failure, we'll have to ensure we have copies of db in different regions so as to avoid single point of failure

Future improvements

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