System requirements

Functional:

1. The Service should return shorten URL
2. The Shorten URL's cn't be deleted.
3. Shorten URL can be a combination of characters and numbers.
4. If given a shorten URL then it should redirect to the original URL

Non-Functional:

1. Scalable
2. Reliable
3. Fault Tolerant

Capacity estimation

1. Write Operations = 100million URL's generated per day
2. Write Operatiosn per second = 1000/(24*3600) = 1160
3. Read Operartions Per second = Considerig 10:1 read to write ratio then read operations = 1160*10 = 11,600
4. Average URL length = 100 bytes
5. 1 day storage = 100million * 100 bytes = 10^10 bytes = 10GB
6. Let's assume that the serivce will run for 10 years = 10GB*10years*365days = 36.5TB

Total sorage needed is 36.5TB

API design

For Url shorteining service we primarly need two API

1. URL Shortening - Client will do a POST request with the original LONG URL to a sample endpoint that might looks like "POST api/v1/data/shorten".
2. URL Redirecting - Client will do a get request with the shorten URl to get the Oiginal URL "GET api/v1/data/redirect"

Database design

For the high level design, mapping of and is stored in relational database along with the ID as primary key.

High-level design

1. As there are more read than writes, mapping is stored im cache to increase performace.
2. Load Balancer is introduced to handle and distrubute the load evenly to web servers.
3. IF the short URL already in cache then return it, if not then get the short URL from database and store the mapping in cache for future references.

Request flows

1. Long URL is the input.
2. System Checks if Long URL exist in the database.
3. If it exisit the it means then the URL has already been queried before. The system responds back with the short url.
4. If not then New ID is generated for the long Url.
5. Apporiate Algorithm is written to convert the Long Url to short URL.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

While URl redirecting we can have 2 Status codes. response cde 301 and 302. with response code 301 the browser will permanently store the response in the cache so any subsequent request for the same URL will niot be sent to the shortening service. For 302 response code the browser "temporarily stores the result" hemce each reque4st is redirected to long URL increasing the latency.

Failure scenarios/bottlenecks

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

Future improvements

1. We can introduce rate limiters to manage exessive load and Dos and DDos attack.
2. Database scaling or sharding is another technique that we can implement for efficient querying and resource management.