Requirements


Functional Requirements:


  • Create a short URL for a given long URL.
  • Return the long URL associated with a given short URL.



Non-Functional Requirements:


  • System should be scalable
  • System should handle durable
  • System should be able to handle heavy traffic (high throughput, low latency)


Capacity Estimation


  • considering their are 100 new long url registered daily. So, to keep it simple if the long url takes 10 bytes of space and short url takes 5 bytes of space then in order to store 1 record in db it will take 15 bytes. As we are considering daily 100 new urls registered the space required to store 100 urls daily would be 100 * 15 = 1500 bytes minimum. If we consider a time period of lets say 5 years then it would be 1500 * 5 * 365 = 27, 37, 500 bytes. So, 28, 37, 500 bytes of memory we need to provision in order to store 5 years of data.


API Design

The API service following REST architecture performs 2 operations (endpoints):

  1. POST a long url and get the short url by passing it to hash functions in order to reduce the size of it and store the mapping of long url to short url in db.
  2. Make a GET call in order to get long url on the basis of short url for redirection


High-Level Design







Database Design

  1. We will use a SQL database like PostgreSql or any other sql DBs
  2. Will use a cache layer (write though strategy) with a TTL for duration based on user subscription (if a user has a subscription of tiny url service for 1 year the long url will be returned for the short url for 2 years only).


Detailed Component Design

  1. clients could be of 2 types one who posts the long url in order to get the short url (POST call to Tiny Url Server)
  2. clients who hit the short url in order to get the long url (GET call to Tiny Url Server)
  3. tiny url service creates a mapping (entry) in the db for long and short url mapping. And algorithm (hash function) which runs in order to generate short url from long url. Tiny url service also gets the long url based on short url.
  4. Cache / Redis - all the request goes to cache first if its a hit that means key exists in cache and the data is fetch from cache and returned to client. In case of cache miss if its the very first hit it calls goes to the db creates and entry in cache and response is returned to the client. If the client subscription ended we will end 3XX status code (301 resource move permanently)
  5. Database - SQL database to store the records (create and delete based on subscription) will store short url, long url, and timestamp