Design URL Shortening Service

Clarification questions

  • How the customer experience will looks like ?
    • Customer may wants to use simple number and letters instead of symbols, special characters.
    • Customer can create custom URL if they are willing to pay extra
    • Customer can decide till when this shortened URL should exist ?

Back of the envelope estimations

  • Total expected URLs : 1million, it can grow in future
    • Let’s say, we use letter and numbers only
    • 26 + 10 = 36 combinations we can used and url length can be 6,
    • so total 366 = 2 billions URLs system should handle.
  • Total expected redirections : 1 millions, it can grow in future
  • How may total users are there in systems ?
  • How may actives users on daily basis ?
  • How much is the storage will be required ?
    • save original URL = 100 char
    • shortend URL = 6 char
    • Total Storage = (100+6) * 1 million new URLS = 100 million ~ 100 MB per day
    • Yearly ~ 100 MB * 365 = 36500 MB = 36.5 GB
  • Transaction per second
    • Write Request per day : 1 million new URLS
    • Read Request per day : 10 million reads ~ 10 * 106 Request ~ 107
      • Seconds per day : 84000 ~ 105
      • Transaction per seconds : 107/ 105 ~ 100 read request per second
    • How many servers required
      • Single server can handle appoximately ~ 10000 requests
      • Servers = Transaction per seconds / 10000 = 100 / 10000 ~ 1 server

Functional requirements

  • User should able to create URL
  • User should able to verify/test redirection working

API’s

  • <Domain.com>:443/urlservice/v1/urls/create
    • create – Post HTTP Method
      • Body
        • user_id
        • original_url
        • custom_output_url <optional shortened_url>
      • Response
        • user_id
        • original url
        • output_url <shortened_url>
      • ErrorCodes: 200 ok, 4xx not found, 5xx service down, service errors etc
  • <Domain.com>:443/urlservice/v1/urls/get?url=<shortened_url>
    • get – Get HTTP Method
  • Header
    • Authorization token (JWT token)
    • Authentication system :
      • No need of login ?
      • OAuth (Off the shelves)
    • Content type : json etc
    • user_id

Non Functional requirements

Availability

  • Service should be up and running all the time
  • Primary and additional hot secondary server will do the job.

Latency

  • API Response time : Three 9’s availability is fine ~ 100 ms response time.
  • To decrease load on backend server (celebrity problem), we can introduce cache (Redis/memcached).
  • To reduce latency on customer’s point of view, if bugdet if available we can introduce CDN to cache hot URL’s in different geographical areas near to edge locations.

Reliability (Partition tolerance)

  • We can use distributed server

Leave a Reply

Your email address will not be published. Required fields are marked *