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 - We will first hash the original_url with secret key on the BE side and then we take the first 6-7bytes and create a base62 decoded hash. this way we will have not guessable sequence of keys and only our server can actually decode it.

1. Compute HMAC-SHA256(secret_key, original_url) → get a 256-bit (32-byte) hash.
2. Take the first 6–7 bytes (48–56 bits) of the hash to keep the output short. 
3. Encode those bytes into Base62 (not Base64, to avoid special characters like + and /). 
4. Truncate or pad to our desired length (e.g., 7 characters). 

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.

high availability - we have a lot of small workers and scaling rules in our infrastructure provider - for example http based scaling for the message context creators and then queue message count based scaling for the generators of hash. Database is dynamoDB which is geo-replicated and has automatic sync between the regions.

low-latency - is satisfied with the horizontal scaling we have separate workers for the hash generation and load balancer to send the context input of user to the context message creators. Low latency for redirecting is simply done by more smaller workers that will return the res.redirect based on the shorten-url hash given on the /:hash route.

rate-limiter - to /:hash for 10requests per minute per IP. I think we dont have to be concern about anything more as long as the urls are public. if they are private