System requirements

Functional:

• account management
• URL shortening
• URL management
• URL redirecting

Non-Functional:

• High Availability
• High latency
• Security
• Efficiency of Shortening URL
• Highly reduced redirect time

Capacity estimation

• DAU: 10M
• shortening / visit ratio 1: 1K
• shortenings per day: 10K
• visits per day: ~10k
• visits per second: 3k

• unique URL field length: 1 byte (English alphabet + numbers)
• number of URLs supported: ~ 20T
• as per daily shortenings URLs will be available for 2B days / 5M years more than enough

API design

Account Endpoints:

• POST api/user/register > user registration
• POST api/user/login > user login
• GET api/user/me > get account data

URL Endpoints:

• POST api/url/shorten
  • body: original URL

shortens and returns the new URL

• GET api/url/my-urls > returns URLs associated with the account
• GET redirect/:shortened-url > redirects to the original url after performing db lookup

Database design

User:

• userid : bigint
• email
• password
• fname
• lname

URL:

• urlid: bigint
• original-url
• shortened-url - indexed by shortened URL
• userid

Request flows

• Shortening
  1. user sends shorten request with the original URL
  2. the backend server generates unique shortened URL and stores the pair in DB
  3. The shortened URL is returned to the user
• Redirecting
  1. A visitor clicks on the shortened URL
  2. The request is sent to the backend server
  3. the backend server retrieves the unique string from the URL
  4. the matching pair is looked from CDN
  5. if not, match is found in CDN it is retrieved from DB
  6. the user is redirected to the corresponding Original URL

Detailed component design

Trade offs/Tech choices

Failure scenarios/bottlenecks

multiple users may try to generate url at same time creating similar url for diferent redirects

Future improvements