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

User submit registration or login details

Service validates credential and create or return user account and auth token

User send a request to create a short url

Service check user's creation limit

Service generate an unique short code if limit hasn't been reached

Service stores the mapping of the newly created url in database

User access to genearte shortUrl

Service look upo in the database

If found, lomg url is returned

Service update access count in databse

Detailed component design

Generate URL :

1. Long URL is received via API
2. Check if long url is in DB, If yes return short url, otherwise go to the next step
3. Generate Url Service converts the url using hash function(ie. CRC32, MD5, SHA-1) or a BASE62 conversion - Let's say we use BASE 62 because we can avoid collision
4. Store long, and short ulr in db and their ID in db
5. retrun short url to customer

URL redirect :

1. get short url
2. load balancer forward the request to the web server
3. server check cache first, if there return, if not there read from db
4. return longurl

Trade offs/Tech choices

I gave priority to speed of retrieving data by suggetsing a caching and DB storing solution.

Considering we will have more traffic for reading than writing, I suggest a master / slave approach, with the master DB being write only, and slave DBs being read only.

On launch of the platform, we can probably start with a monolith, it will get us quicly to the market, and it will help with debugging errors.

The APIs should provide all it needs

We haven't considered different geolocation, and we haven't deep dived into any scaling options.

Failure scenarios/bottlenecks

Bottlenecks :

1. Too many access per customer, we need to implement a rate limiter per customer

Failure scenario :

1. API down - It is important to promptly notify customers
2. DB connection down - We could implement a message queue system to temporary store data to saved in DB when back

Future improvements

Migrate to micorservices(one for creating the shortuRL, one for retrieving), so if for example the generateShortURL goes down, the customer can still access the generated URL, and viceversa.

We should consider sharding to scale the DBs, and geodistribution.

We should also add WAF in front on the login to prevent ddos attack.

We should define best authentication and authorizetion technique. For this platform OAuth 2.0 shoudl work perfectly, especially because of the access token and refresh access token features, which can be important to keep customers safely logged in