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:

List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

API Design

/shorten - input is long url, it will return new url in format: urlShortener.io/

/:hash - this will take the hash of long url and redirect user from the original requested url to the long url.

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

client - sends input to app

api - retrieves data, app logic:

1. Hashing service with mechanism I think base62 is good enough with encoding (using characters 0-9, a-z, A-Z). then If this system scales we will first check if generated hash is already in database - if yes then this url is already in database and we can return this one. I assure the uniqueness by checking the database first. Every url that comes in and is hashed with the base62 will return the same hash. This will provide uniqueness
2. Redirect service - when a client calls to /:hash route we will return res.redirect to long url.

Write path- user sends a long url to /shorten - internally app calls hasning service which will create a hash and lookup this hash in database to check if provided long url already exists. Returns that url or create a new record with this hash and return the newly created hash.

Read path - user calls /:hash of our service the redirect service will get the long-url from database based on the hash provided and return res.redirect to the long-url.

queue - if we want to scale we can introduce later a queue that will switch our architecture into event-driven. User will then pool for the url shortener a couple of seconds I think its still not a problem to wait couple of seconds for reply to create url shortener.

database - noSql database that keeps track of what hashes we already used and what short_url/long_url is it associated with.

basically dynamoDB or any key-value database should handle the scale effortlessly.

cache - we can cache the data based on the hashed key.

load-balancer - we will use load balancer when we need to scale to more servers and event driven architecture to scale this solution.

Detailed Component Design

queue - could be any queue that will accept the same input and call the hashing and database write etc in separate call no asynchronous calling. If we miss cache we first look to database and create a new record, cache will have TTL 1 hour.

database - key value dynamoDB which will have 1(O) return time even on scale. It automatically handles partitioning under the hood by adding a global indexes and sortKeys.

hashing - using 62^5 = 916,132,832 this hashing algorithm will always return the same sequence of characters if we insert a same sequence of characters into this. If we exhaust the 5 characters we can just simply add a new one. To avoid collisions we have to first check the DB thats why we have dynamoDB to be extremely fast and reliable at scale.

load balancing - we will have a queue and event-driven architecture. So what we can do is to jut use a load-balancer to use 3 servers that will create the context for generation of short url and we will have workers to take care of the generation that will be subscribed to the queue.