How does TinyURL work?

  Google
Add Your Answer
Answers (4)

A simple way to understand its working is with the help of an analogy.

 

You and your mom have gone to a local store to purchase some goods. The store is named “THE GREAT INDIAN STORE”. Now you forgot the cash and the digital payment systems are down. However, as you have a good relationship with the store owner and you are a frequent buyer the owner has asked you to pay when the digital payment systems are good.

You save the mobile number as “TGIS” because you are lazy and don’t want to type the whole name.

You go home and pay the bill using net banking and now you want to call the store owner. Your mother asks you to call “THE GREAT INDIAN STORE” but you call it “TGIS” because you know you have saved the number with that name.

And there you go!

Clarifying Questions

  • To make sure – we’re talking about how tinyURL actually generates a shortened URL, right?

    • Yes

  • You want me to focus on technical user journey?

    • Yes

  • Focus on user path of generating a single URL one-time? In other words, we aren’t looking at some type of a link tree or something with a custom domain?

    • Yes

 

Describe the product

 

User journey:

  1. User finds a link they want to share with a friend or print on a poster, etc.

  2. User enters URL into tinyURL

  3. User receives shortened URL that is valid for X days or hours

  4. User sends the URL to a friend or prints on a page

  5. Friend or other person enters URL into the browser

  6. Person is redirected to the original URL

 

Attributes

 

  1. Time limit the link is valid

  2. Time to redirect when the second user enters the URL into their browser

  3. Length of the URL (shorter is better)

  4. Readability of the URL – how easily can somebody copy this down or, better yet, remember it?

  5. Number of collision-resistant URLs

  6. Database size/cost of hash map etc. for tiny URLs

 

Goal

 

  1. Skip – not necessary here

 

Attributes (prioritized)

 

  1. Number of collision-resistant URLs

  2. Length of the URL

  3. Database size/cost

  4. Readbility

 

Design the product

 

  1. One way hash w lookup

    1. Hash the original

    2. Return shortened URL w hash

    3. Store key-value pair with generation and expiration dates

    4. When user retrieves URL, lookup in table

  2. Two-way hash

    1. No DB required

    2. Two-way hash function can either generate or retrieve a URL

  3. Random name generator

    1. Use random dictionary of names and DB

 

Tradeoffs

 

  1. One way hash function requires DB

  2. Two-way hash function does not have expiration, does not require DB

  3. Two-way hash function is more likely to have collision errors (probably)

  4. Random name generator more likely to have collisions

    1. Needs routine updating and maintenance or shorter life time

 

Summary

 

  1. Probably would go with one way hash with lookup for free tier

  2. Longer expiration and readable names become possible with paid tier

    1. Revenue can pay for maintenance and DB costs

 

Clarification question:

Tiny URL is shortened version of an otherwise long URL:

google.com/photos/album/12312/ – >tiny.url /123

 

Applications:

– SMSs where length is short

– Mktg communication,

– etc

 

Key attributes: Tiny URL is:

– Fast to create

– Fast to redirect

– Easy to remember – shorter the better

 

Goal:

How does tiny URL work

 

Answer:

Following is the flow of request/ response and how the systems work together:

It is linear to and fro flow:

(facing some challenges uploading a screen shot of flow, hence typing it here)

 

Step 1: User browser:

User enters a long URL to shorten: google.com/photos/album/123123

or

 

User enters/ clicks tiny URL to access the website

Step 2: Hashes cached

Existing hashes are cached on edge server for quick search and response.

When user types in a tiny URL, the cached hashes are searched and DB is not hit

Step 3: Mapping cached

Mapping of Hashes to URL is cached on edge server for quick search and response.

When an exsiting hash is identified, URL is identified from this mapping. Again DB is not hit.

Step 4: Hashes creation/ storing in DB (Stores list of used hashes)

When a request for new tiny URL creation comes in, a hash creation algo is run.

The algo must has a criteria along length of hash to keep the URL short.

DB is where the data is actually stored. Once a record is created, it updates the cache.

12
13
322
Step 5: Mapping in DB
This is where the data is actually stored. Once a record is created, it updates the cache.
12 -> google.com/photos/album/123123
13 -> linkedin.com/chanp/12312312

Google technical interview question: How does TinyURL work?

Clarifying Question –

1.      Just to make sure we are on the same page TinyURL is URL shortening service where a user enters a really long such as mydomain.com/reallylongstuffhere/morelongstuf/maybeishouldhaveshorterurls

 

and in exchange TinyURL gives the user
tinyurl.com/ hashkey.

When someone puts  the tinyurl.com/ hashkey into their browser they end up at mydomain.com/reallylongstuffhere/morelongstuf/maybeishouldhaveshorterurls

 

2.       And when you say works – you would like me to describe the technical journey behind a user entering tinyurl.com/hashkey into their browser and ending up at mydomain.com/reallylongstuffhere/morelongstuf/maybeishouldhaveshorterurls

 

Technical answer

A user generates a tinyurl by entering into a tinyurl website or via API.  Tiny url uses a hashing algorithm to convert the long url into a hash key.  This hashkey is stored as a lookup key that returns the long url.  The hashkey can be stored in a highly indexed fashion to speed retrieval.  The hashkey as is used as the main identifier in the url.  Tinyurl.com/hashkey

 

Lets switch sides to the a user who enters the tinyurl into their browser.

The user enters tinyurl.com/hashkey into their browser the user’s browser sends that request to the users ISP where a domain server translates the text into an IP address.  An IP address  is a string of numbers that uniquely identifies where that web request should be routed.

In this case the user is routed to TinyURl.com.

Tinyurl must return the data very quickly so the request is sent into a load balancer that accounts for both the users geographic location and server load.  And routes the request a close server with capacity.

The hashkey is likely stored in a memory-based cache layer – or at least those urls (hashkey) that have been used recently.  This eliminates the need for a disk or origin lookup.  If not in cache then the hash is looked up in the DB.  The hashkey is associated to the full url and the user is redirected to the full url.

diagram at https://ibb.co/7pWV0zM

 

So the really short answer is that tinyurl works a lot like a mail forwarding service.