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.)...
• The redirect service should be fast and accurate
• High availability should be there the system should not go down when we call anything
• The redirect service must response to user request within 100 millilcon.
• Must accurately mappen short url to its long url , huaranteeing no error or conflicts
• the system should be fault tolerant

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

Post - api/vi/createURL { longUrl ,userId, timestamp , return short url}

get -> api/v1/getLongUrl{ short url, userId}

301,302

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.

Components will be user, write server , read server, database and cache for quering highly asked APIS

The architecture will be microservice architecture and we can store it whenever needed

Write server - will have convert long to short url

1. we can apply a hashing technique to create a unique short url and at the same time
2. for hashing we will choose base62 conversion cause it will have more combination of keys
   1. we will store the long url with autincrement id
   2. convert id to base62 and return that as short url

Read server - We can use redis for freq reads else we use Db calls

LFU cache in redis

We will also have a load balance to ensure system is not overloaded

Database /Storage- user id, id, long url , short url

for write we will come to database store the shorturl and retrieve it to user

for read at first we will come to db for a new request and based on location wise we will store the freq queried short url to redis and keep it there

We also can create a read write replica where db will have read schemas and right ones. in this way write can not be disturbed and once the read storage are replciated we can have them used .

for a better handling of keys we can pre compute some keys and create a table of used and unused keys

We can shard the date by short code

1. Write server → ask ID service → gets numeric id
2. Convert id → Base62 → shortCode
3. Store in DB shard based on id

RDBMS - like a dynamo db or mysql

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

ID Generation —

1. When the user will talk to write server we need to have a rate limiter per clientid so that he can not do maybe 10 api generation per min
2. During write first we will go for id generation servive we can go with DB autoincremaent for start or else we cna have a snowflake epoch counter
3. When we will get the id we will perform base62 conversion and then get the short code now we will insert that into the DB and return the user the short code
4. incase of user has an alias we can check that too if that is available to us else we say no
5. Incase used put the same long url then we can check
   1. first we get the new code
   2. if we dont want to send the new code lets have a client token + unique contraint key (user_id,long_url_hash)
   3. idempotency_key - if client is regiseted used that else either use idempotency-key-header. or anon_id(cookie)
   4. x-fingerprint + tinyUUID
6. We can use id generation service to pre compute id before and store it into a sepaerte db based on used and unused id and this way things can be managed.
7. For colloision snowflas id is designg deo be uniwi, timestamp+machine id+sequence,
8. for colloion in db we have a unique key constraint of id and shorted so reqtey
9. we can also have id generateion service run on mutiple instact via load bapalceed
10. We can have Redis INCR for backid and flag /mettic and go to DB autoicrmenet for primary right shard
11. Circuit breaker to specify anything wron, monitoring needs to be there

Caching — Scenario Checks

1. When we miss cache we go into the db and fetch that record and use LFU to enter that
2. We can also have a cache invalidation request periosfically
3. As well as we can have a TTL for each cache with LFU for volatile

What specific approach will you take for cache purging when a link is disabled or edited?

Purge strategy (update/disable):

• Source of truth = DB. On any change (disable/expire/update long URL), write path does: DB update → publish “link_changed(shortCode)” event → cache delete.
• Redis action: DEL shortCode (and any secondary keys like longUrlHash→shortCode). Next read repopulates from DB. For “disabled”, you can also set a tombstone key so it doesn’t keep hammering DB.

What specific TTL or eviction policy will you implement to balance freshness and memorys

Ans TTL for each cache with LFU for volatile

What specific strategies will you implement to mitigate hotspots and ensure an even traffic spread

detect hotspots via metrics (top-N shortCodes by QPS), auto-flag “hot keys” to edge-cache longer or pin to L1 cache, and alert on sudden traffic skew.

Rate limiting -

1. Egde + oer user rate limitieng \
2. Write server will have global limiter + small bounder queue = queue full 429
3. Backoff guidanve, retry after 2
4. DB/redis latency spike we go into mode fo burt and trhor 429
5. Idempotecy for safe retries check user id, and
6. hotkey -- serve via cahce dns and apply per key throtlles to avoid redis /db stampede

How will you handle generator outages or split-brain scenarios?

1. Mutli instace id geneterat- every genertor will get a machine id lesasd from a single source of truth,
2. leaase will retnwe it it fails that generator will stop issueing id
3. Monotonic/clock safety (Snowflake hardening):