System requirements

Functional:

1.long to short function. if user give a long url, it will generate short url.

2.short to long function. if user give a short url, it will redirect to the long url

3.url should have a expiration time, if for a certain time, no traffic then we can remove this short url from our database.

4.we can also have analysis function to record and track top hot urls from user

Non-Functional:

List non-functional requirements for the system...

Capacity estimation

lets say it is read heavy. 1 write 5 read.

suppose every minute there is 60 new url generating request, then the write QPS would be 1/s and the read QPS would be 5/s

and every hour, there will be 3600 new short url generated and 3600*5 redirect request, aka short to long. suppose avg write request need 100B, then 1 minute is 6KB, and one day is 8.64KB and 100 day is 0.864GB.

Given the scenario where the write request rate is 1000 requests per second and the read request rate is 5000 requests per second, with an average request size of 100 bytes, we can calculate the total required bandwidth as follows:

• 
  
• Total Requests per second: $1000 \text{ writes/s} + 5000 \text{ reads/s} = 6000 \text{ requests/s}$
• 
  
• Total Bandwidth per second: $6000 \text{ requests/s} \times 100 \text{ bytes/request} = 600000 \text{ bytes/s} = 600 \text{ MB/s}$

API design

for a given long url, it will generate short url and return back.

String generateShortUrl(String url);

if user give a short url, it will return back the original long url

String getOriginalUrl(String shortUrl);

user can delete a short url sending in the short url and it will delete the record inside the db

boolean deleteUrl(String longURL)

Database design

we need a long_short_url table{

String id,

String shorturl,

String longUrl,

Date expirationDate

}

High-level design

Request flows

1.user send a long url, it gose into our load balancer and forward to one of our host, it will first check our database to see if already exists, if yes ,then it will return back the existing one inside the db immediately it then execute the long to short api and generate the short url,and store the one on one mapping into the database, and calculate the expirationdate and store all these information in the database and finally return to customer the short url.

2.when user send a short url, it will first goes into our load balancer and forward into our host, and then do a query in our database and if record found then it will return back the long url, otherwise return empty.

3.when user send a delete request with either long or short url, it will first go into our load balancer and execute the api, then it will check the database and find the corresponding record and set the expireationDate to now, and there will be batch processing to delete the expired record everyday.

Detailed component design

1.database we use mysql relational db

2.we have 3 major apis, sendlongurl return short url, send short url return long url, send either long or short url make the expirationDate as now

we have caching redis to make the read optimization, we have batch jobs runs daily to remove expired records, we have rate limit function to throttle by ip to prevent single user abuse

Trade offs/Tech choices

Database Replicas:

• 
  
• Pros: Database replicas can improve read performance, increase availability, and provide fault tolerance by distributing the read load and ensuring data redundancy.
• 
  
• Cons: Introducing database replicas can add complexity to the system, incur additional costs for hardware and maintenance, and potentially introduce latency for data synchronization between replicas. Running daily batch jobs on replicas might cause downtime or impact performance during maintenance.

Redis Cache:

• 
  
• Pros: Redis cache can significantly improve read performance by storing frequently accessed data in memory, reducing the load on the database, and speeding up retrieval times for hot data.
• 
  
• Cons: Initially populating the cache (cache warm-up) can introduce latency, especially for large datasets. It requires careful management to ensure data consistency between the cache and the database.

Failure scenarios/bottlenecks

database connection pool size has a limitation, if it reach the limitation, it would cause high latency and no space for the new request

Future improvements

adding more database instance, setup the idle timeout to clean up and release resource in time,