System requirements

Functional:

Functional Requirements:

1. URL Shortening: Users can input a long URL and receive a shortened version.
2. Redirection: Users can access the long URL by entering the short URL in a browser. The service should redirect them to the corresponding long URL.
3. Analytics: Users can see metrics related to clicks on their short URLs, such as the number of times the URL was accessed.
4. Custom URLs: Users have the option to create custom short URLs instead of randomly generated ones.
5. Link Expiry: Users can set an expiry date for their shortened links.
6. User Accounts: Having an optional account system for users to manage their shortened links.

Non-Functional:

1. Performance: The system should handle up to 10,000 URL shortening requests per second.
2. Scalability: The architecture should support scaling to handle increases in traffic without degradation in performance.
3. Availability: The service should achieve high availability, ideally 99.9%.
4. Security: The system should be secure from common vulnerabilities (e.g., SQL injections, XSS) and protect user data.
5. Usability: The user interface must be intuitive and easy to use for the end-users.

Notes: Read vs Write -> Skews heavily towards reads

Capacity estimation

10,000 RPS means at least 20,000 RPS for checking and creating a short url (means we need a load balancer/request proceeor/gateway)

assume each short url is 8 characters -> 9 bytes per short url

-> 9 * 10000 = 90000 bytes per second -> roughly 9gb per day in just new short urls

assume each short url is 16 characters -> 17 bytes per short url

-> 17 * 10000 = 170000 bytes per second -> roughly 9gb per day in just new short urls -> 17 gb per day in long urls

each URL gets a integer for count metrics -> 4 bytes

Final Capacity per User

User -> user id + 9 + 17 + 4 bytes + timestamp(13 bytes) per user stored

API design

Define what APIs are expected from the system...

Creation API:

• Input: Long URL + Custom + TTL
• Input: Long URL + TTL
• Output: Custom/Generated URL

Metrics API:

• Input: User ID
• Output: List of all short urls + metric counts

Retrieve API:

• Input:Custom URL
• Output: Long URL

Database design

Use NOSQL database design

Table Called USERS

Each table in Users contains

USER ID: Unique String ID per USER (Partition Key)

SHORT URL: Short URL in string (Sort Key)

LONG URL: LONG URL in string

TTL: Short URL Time to Live (Timestamp)

Table Called USER_METRICS

Each table in USER_METRICS contains

USER ID: Unique String ID per USER (Partition Key)

SHORT URL: Short URL in string (Sort Key)

Metrics: Count of clicks

High-level design

Gateway/Request -> Service/Server -> Database

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

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

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

Failure scenarios/bottlenecks

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

Future improvements

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