System requirements

Functional:

1. Shorten URL: The user should be able to enter a long URL and receive a shortened alias that redirects to the original URL.
2. Redirect: When a user accesses the shortened URL, the service should redirect them to the original long URL.
3. Custom Aliases: Users should have the option to create custom aliases for their shortened URLs instead of random strings.
4. Analytics: The system should provide users with analytics about their shortened links, including click count, geographic location of clicks, and referrer information.
5. Link Expiration: Users should have the option to set an expiration date for the shortened link.
6. User Accounts: Users can create accounts to manage their links, view analytics, and access/edit their shortened URLs.
7. API Access: An API should be available for developers to integrate URL shortening functionality into their own applications.
8. Integration with Social Media: The service could provide tools to easily share shortened URLs on various social media platforms.

Non-Functional:

1. Scalability: The system should handle a growing number of users and URLs without degradation in performance. This includes horizontal scaling to accommodate high traffic.
2. Reliability: The service should be consistently available, with high uptime (e.g., 99.9% availability). It should gracefully handle errors and outages.
3. Performance: The system should provide quick response times for shortening URLs (ideally within milliseconds) and redirection (under 200 milliseconds).
4. Security: User data should be encrypted both in transit and at rest. The system should implement measures to prevent abuse, such as spam and malicious links.
5. Maintainability: The system should be designed to allow for easy updates and additions of new features without significant downtime or risk of failure.
6. Usability: The web and mobile interfaces should be intuitive and user-friendly, minimizing the number of steps required to shorten a URL.
7. Data Consistency: The service should ensure that all interactions with the database (e.g., creating, updating, deleting URLs) maintain data integrity.
8. Analytics Storage Capacity: The service should efficiently store and retrieve analytics data regarding the usage of shortened URLs without performance degradation.

Capacity estimation

Estimate the scale of the system you are going to design...

DAU = 5 * 10 ^ 6

Request per day per user = 2

Request per second = 5 * 10 ^ 6 / 24 * 60 * 60 = 116

Link size = 100bytes

CLicks per day per link = 100

Amount of memory for links for a year = 116 * 60 * 60 * 24 * 365 * 100 = 3.4 GB

API design

2 Functions:

1) POST shortUrl/v1, BODY: longURL, RETURN: shortURL, STATUS: REDIRECT

2) GET shortUrl/v1, REQUEST PARAM: shortURL, RETURN: longURL, STATUS: REDIRECT

Database design

class User{

   +Int ID

   +Int UserID

   +String Name

   +String HashedPassword

   +String Email

   +CreatedAt

  }

  class LinkEntry{

   + RecordID

   + UserID

   + EntryID

   +int clickCount

   +String shortURL

   +String longURL

   +CreatedAT

  }

High-level design

Request flows

For POST

1) Clients request Load balancer IP from a DNS service

2) Load balancer redirects request to one of the app servers

3) App server either encodes the long url to short url or forwards request to an encoding service

4) Encoded URL is stored in cache (if it fits)

5) ENcoded URL is stored in the database

For Get

1) Clients request Load balancer IP from a DNS service

2) Load balancer redirects request to one of the app servers

3) App servers retrieves longURL from cache (if it exists)

4) App server retrieves longURL from database

Detailed component design

Use md5 or base62 to encode the URL

If application servers can't handle the encoding we can use a separate encoding Service

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

1) Load balancer failure: another replica takes it's turn

2) Application server fail: another replicate takes it's turn

3) if LinkDatabase master fails it's ReadReplica is promoted ot master

Future improvements

1) Scale database layer based on the number of links, shard it by shortUrlHash

2) Add global session management in applicaiton layer