System requirements

Functional:

1.Need to generate shortened url for the given url

2.for given shortened URL need to retrieve original full URL and redirect to original url

3check id shortned url is valid and already exist in system , if exist already then return erro

Non-Functional:

1should be high available and fault tolerance

2should be low latency

3should be able to handle large amount of data

4should support growing number of user

5 Security requirement authentication and authorization and confidentiality, injection and DOS attack proofing

Capacity estimation

1. approx 1 ml active user per month upto 1bl total user

2. Average 10 ml shortened request per month , peak may upto more than 1bn

3.Size of max long url support upto 500 byte with

Size of shorten url 8byte base 62 average, monthy database size

508byte * 10ml = 5gb

4.Clicks per shortened URL per month: 1000

5.Peak hourly traffic: 10% of monthly traffic (100,000 URLs shortened, 1 million clicks)

6 1 : 200 write /read ratioj , for 100 ml write read

20bl

7 Peak hourly 10% of monthly 2bl

API design

Define what APIs are expected from the system...

Rest Apis

Redirect Service

1. Post /generateUrl?longurl=

-create new short url save in system and respond with 201

Generator service

1. Get /redirect/$shorrurl

take request for given short url from path parameter, retrieve original url

-and redirect to original url 308

• 404 if not found

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Entity User

• userid
• name
• pwd
• created_at

ShortUrl

• id
• shortUrl (index) shard part
• OriginalUrl
• Created_by
• created_at

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

RedirectionService : This service serve for click shorten url link and will try to check orignal url from cache/ db for shorten url hash and redirect to original url

Generator Service : Takes url generatrion requiest create hash (re hash till unique found) and save in DB

Cache local/distributed : Store key value information of short/original url and serve fast save db read

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Database need to replicate for FT and high availability and consider nosql db for high read/write through put and scalability ,

GeneratorSevice : This service can create hash for given url with auto generted id or timestamp for increased uniqueness of hash , if still hash collide can rehash original hash and send .

Should handle invalid input to mitigate injection attack

Can implement rate limiter for mitigate DOS

RedirecrtSevice Should validate input for valid charters and any injection attack , handle error not found .

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Some trade off and choice can be made for db consistency vs high availbility in design db cluster . If need low latency and HA may need to sacrifice conssistency

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

With weak consistency there could be possible fake miss cache in read replica db

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?