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. Conflicts will be handled by unique index on hash saved to DB if there is already hash with the value we want to save we compare the original_url if its the same we return this HMAC is deterministic.

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.

Compute HMAC-SHA256(secret_key, original_url) → get a 256-bit (32-byte) hash.
Take the first 6–7 bytes (48–56 bits) of the hash to keep the output short.
Encode those bytes into Base62 (not Base64, to avoid special characters like + and /).
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

cache - we can cache the data based on the hashed key. and use Least Recently used eviction policy to remove the most stale data.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10