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.)...
• availibity >> consistancy
• Scalability && realiability

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...

~ 30 million per day * 365 = < ~1B Links created per year

POST : /shortenurl

body :{

originalUrl : longurl (0 to 9 & A^Z & a^z )(7 chartcter long)

}

response :

{status : 201, shorturl : shorturl}

Get : /abc6547.bitx -> 301 (permanent redirect) -> 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.

As of now we are assuming there will be 100 millions users using this service and creating around ~1B short urls. After thinking about this criateria I dicidede to use 7 charatcter big string as url which will have

(0 to 9 & A^Z & a^z )(7 chartcter long) I believe thats enough considering our criateria.

createing the url :

-> user send post request to microservice through APIgatway with body constaining long url it will respond wwith status code 201(created ) and shorten url It will sstore data in DB

this will be schema for one long url: Url

LongUrl : we will store long url ,

shorturl: we will also store short url (we will lmake sure this acts as unique id ),

createdby,

created_at,

expiration_time

the way we will generate is converting number (1000000 -> base62) which will give us the shhorturl we want

using the short url :

client will enter the short url iin browser which will reach out to us our microservice will find that in database and redirect user to actual url (permanent redirect 301).

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.

while creating the url

problem :

-> they can be possibility that multiple instance use same number if we keep that number random so good solution is to keep that long number to redis service or zo-keeper and read it from there that will help us having the centralized source of truth for that number.

again reading every single time from Redis or zokeeper introduce latency so we can manages the batch like 100000-200000 (number is owned by instance A) 200000-300000 number owned by service B and that how we create if instance A reached to limit it ask for next set of numbers and if it died number will be west but its okay having such big system can ignore few housand numbers..

while redirecting

lets say we are analising that out of all the urls we created 10000 url users using every seconds , so its best to stoore this 10000 urls in inmemory db like redis than everysingle second looking at db. so introducing inmemory db there would save lot of time I believe