Requirements

Functional Requirements:

• Hosted website for users to enter URLs
• User enters URL -> Hits submit -> A shortened URL (say, less than 10 characters?) is returned
• On our side, a record mapping our shortened URL to the user's desired URL is recorded
  • i.e. shortened URLs should also be consistent
• When a user accesses the shortened URL, we look up the matching URL record, and re-route them to the longer URL
• If a URL fails to resolve (broken link, high traffic), we must continue to serve redirects in order to maintain availability
  • on this note, maybe do an initial check at 'shorten' time to make sure that the website is available / valid?

Non-Functional Requirements:

• Shortened URL should return near instantly (<1s?)
• Many users should be able to shorten URLs at one time, ability to scale horizontally in order to handle any spikes in traffic
• Re-route upon access of shortened URL should be near instantly (<1s?)

Capacity Estimation

• Could be up to 1000s of users shortening per day
  • Can assume most URLs are unique, though there may be duplicates
  • Will need to store URL ID -> URL in order for look up, so storage is a factor (though probably nothing crazy -- URL is a matter of bytes to store if we are storing URLs up to say 500 characters with an ID for the shortened URL ID)
• Many more users accessing shortened URLs on a daily basis -> 1 person may shorten a URL that 10k ppl click on

API Design

• /api/v1/shorten?url={url}
  • url = long URL to be shortened
  • returns shortened URL, e.g. 'https://www.tiny.io/url?u=12345' where 12345 (rough ID example) is the shortened URL ID
• /u?u={short_url_id}
  • u = shortened url ID
  • redirects to original url

High-Level Design

• UI/client for users to access, enter a URL to be shortened, and copy/paste the shortened URL
• Backend API for main functionality
  • /api/v1/shorten
    • takes long url, checks cache for existing url record, if exists return the cached URL, otherwise run shortening logic, add new record for the URL pair, and return the new shortened URL
  • /u
    • takes shortened url, looks up the long url, and redirect. periodically check for bouncebacks or errors on redirect, and re-attempt
    • on read of long url, add a 'touch' to the entry so that i can stay alive longer
    • if we look up a url that is no longer cached anywhere, redirect to a 404 / no longer valid page

Database Design

Instead of a database, use a simple Redis or similar cache since we just need to look up key/value pairs and let them be long-lived. In this case the pairs are Long URL <- Short URL ID as well as REV lookup to go the other direction at write time

As mentioned above, /u endpoint will add a touch/heartbeat to any entry that is used.

For GC, can set some sort of lifecycle policy, maybe delete entries that have not been used in 30 days or longer

Detailed Component Design

• ID generation = simple hashing algo (im not sure off the top of my head, but one that results in relatively short hash, could encode from there as well). also could add a salt to ward off attackers. if generator fails, maybe we have a few retries otherwise display error to user to come back later
• i feel like i described caching in db design above