System requirements

Functional:

1. create a new shortened URL from a long URL.
2. Redirect the user to the actual URL from the shortened alias.

Non-Functional:

1. Scalability: Should be able to handle large no. of concurrent requests
2. Availability: Need to be highly available to ensure redirection.
3. Consistency: Need to make sure that the data is consistent and the mapping of URLs to aliases is accurate
4. Fault Tolerance: The system should be able to handle system failures.

Capacity estimation

Considering a user base of 1 million users.

Daily Request: if each user generates up to 5 URLs.

• No. of total URLs in the system: 5 million

If each URL is accessed 10 times a day:

• No. of requests: 50 million requests per day

Assume 5 % of active users at any time :

• Concurrent Load: 0.05*50million = 2.5 million requests per /hour

API design

1. GenerateAlias: Receives a long URL and generates and returns a shortened URL.
2. Redirect: All Shortened URLs are redirected to this endpoint and it redirects them to the actual URL mapped to that alias.

Database design

1. Url Mapping :{long_url, short_url(unique), last_acessed_time,acess_count,created_date,created_user_id}
2. User: {basic details, no. of generated URLs, list of URL mapping IDs.

High-level design

Key Components:

1. Distributed Server
2. Database
3. Distributed Cache
4. Multiple Database replicas Read-Only
5. Load Balancer

Request flows

• The load balancer will receive all the client requests and redirect them to the different nodes of the server.
• All the read requests will go to the cache first, if it is a miss, the data will be fetched from the db replica. The cache will also be updated.
• The write requess will go to the Main DB server. The cache and the replica will be also updated in this case.

Detailed component design

• Handling Database load: Since there will a high ratio of read to write requests, so we will have mutiple db replicas which will help us to distribute the read requests and thus prevent excess load on the main db server.
• Role of Cache: To decrease latency we have cache which will contain the frequently acessed urls. the most recently acessed urls, recently generated urls. This will Reduce db acess request significantly.

Trade offs/Tech choices

1. Data Redundancy for High availability: We have multiple replicas of the same db. This will mean a high level of data redundancy but this will significantly increase the availability and improve fault tolerance of the system by distributing the load.
2. Use of distributed server: Having multiple server instances will help us to distribute the incomming requests thus removing a single point of failure and efficient load distribution.

Failure scenarios/bottlenecks

1. Replication Lag: Due to replication lag some of the newly created data may not be immediately availabel in the replicas. This may result in some urls not being redirected despite being present in the system. To solve this each time there is a write request we will synchronously update the cache with this new data thus it will be imediately available from the cache despite the replication lag.
2. Load Balancer could be a single point of failure.

Future improvements

Load Balacer could be a single point of failure. To handle this we can have two instances of load balancers. With one being active at a time. the inactive load balancer will keep checking the status of the active load balancer (Heart beat) and will take over in case of failure.