System requirements

Functional:

1. User Registration and Authentication.
2. Short URL Generation.
3. User Limits.
4. URL Expiration.
5. Redirection.
6. Analytics Tracking.
7. Error Handling.
8. Performance.
9. Monitoring and Alerting.

Non-Functional:

1. Scalability: The system should handle increased traffic seamlessly.
2. Availability: The service should have an uptime of 99.9% or higher.
3. Performance: Response to redirection requests should be within 100ms under normal load, and support up to 10,000 requests per second during peak traffic.
4. Security: User data must be stored securely, employing encryption and protections against vulnerabilities.
5. Data Integrity: Consistency in the mapping between short and long URLs must be maintained.
6. Usability: The user interface should be intuitive and provide clear feedback to users.
7. Maintainability: The codebase should be well-documented and adhere to best practices.
8. Logging and Auditability: All user actions and significant events should be logged for auditing.
9. Load Balancing: The architecture should support load balancing across multiple servers.
10. Backup and Recovery: Regular backups should be performed, and a disaster recovery plan must be established.

Capacity estimation

Assume we want every URL to be 7 alphanumeric digits. Url can consist of 26 letters and 10 numbers, giving 36 possible characters. 36^7 = 78 364 164 096. The total possible number of combinations 78 billion unique URL.

Datadabase size :

Short URL table will contain :

• unique Id (4bytes)
• short URL (7 bytes)
• access count (4 bytes)

Therefore each record would require approx : 7+4+4 bytes = 15 bytes

78 billion record multiplied by 15bytes = 1097GB

API design

• Sign up :
  • Endpoint : POST /api/user/signup
  • Request Body :

• • Response :
    • 201 Created : User registered correctly
    • 400 Bad Request : Invalid Input Data
• Login
  • Endpoint : POST /api/user/login
  • Request Body :

• • Response :
    • 200 Succesful login with token

• • • 401 Unauthorised: Invalid credentials
• Url creator
  • Endpoint POST /api/urls
  • Headers: Authorization: Bearer {token}
  • Request Body :

• • Response :
    • 201 Created : Short Url created

• • • 400 Bad request : Invalid URL format
• Delete ShortUrl
  • Endpoint : DELETE /api/urls/delete/{short_code}
  • Headers : Authorization: Bearer {token}
  • Response :
    • 204 No content : Short url deleted
    • 404 Not found : Short Url not found
• Redirect to Long Url
  • Endpoint GET /{shortUrl}
  • Response :
    • 302 Found : Redirect short url to original url
• Get User URLs
  • Endpint GET /api/users.urls
  • Headers: Authorisation: Bearer {token}
  • Response :
    • 200 OK : Return list of urls by user

• • • 204 No content : User has no URLs

Get URL Analytics

• Endpoint: GET /api/urls/{short_code}/analytics
• Headers: Authorization: Bearer {token}
• Response:
  • 200 OK: Returns usage statistics for the short URL.

Database design

USER Table :

id - String - Primary Key

name - String - User's name

surname - String - User's surname

password - Hash

created_at - Date - Account creation date

URL

id - String - Primary key

long_url - String - full url

expires_at - date - Expiration date

access_count - int - number of access

user_id - string - reference key

SHORT_URL

id - String - Primary key

short_code - string - generate short url

url_id - string - external key

High-level design

We need APIs for signup, login, URL converter. We need DB to cache most common URL redirect and to store longurl and short URL. We would need a load balancer to distribute the traffic and some monitoring and analytics in place. The URL convertor logic will use MD5

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?