System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1) when shortUrl is given return the original long URL

2) when longUrl is given convert it into shortURL

3) store the mapping of shortUrl, longUrl,expirationtime ( 0-indefinitive, can also provide certain time), createdtime, user, availForFuture(if need to use same URL for future purpose - this is applicable only for 2 years)

4) if any shortUrl is accessed many times, put it in cache

5) deleting the entry of URL from dB as soon as the expiration time is reached

6) error handling when URL mapping is not found

7) user registration for logging-in

8) User metrics would be stored for 5 working days and eom data and eom is maintained for 2 years

Non-Functional:

List non-functional requirements for the system...

1) high availability - should be available for 24/7

2) scalability - when multiple incoming requests increased system should scale horizontally to process them and when there is no load , no. of instances should be decreased

3) return response time should be decreased

4) dashboard to check the performance, capacity metrics

5) setting up database storage threshold, CPU threshold to enable alerts

Capacity estimation

1) 100 requests per second to convert longUrl to shortUrl

2) 500 requests per second to redirect to longUrl using shortUrl

3) 1000 transactions per second

4) 2 database replication instances and 1 master database

5) scale up to 5 instances based on the traffic

API design

Define what APIs are expected from the system...

1) API to return the longUrl when shortUrl is given

2) API to generate shortUrl and store in dB when longUrl is given

3) API for giving the metrics like no. of requests processed

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

USERDETAILS {

string username

datetime registeredTime

string password

}

URLDETAILS {

string longUrl

string shortUrl

datetime createdTime

datetime expirationTime

string user

string availForFuture

}

USERMETRICS {

string user

string reqUrl

string isSuccess

integer noOfConversionsToShortUrl

integer noOfRequests

datetime cobDate

}

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

1) Load balancer

2) Reverse proxy server/CDN

3) Authorization service

4) shortUrl creation service

5) redirection to longUrl service

6) Metrics service

7) Database

8) cache

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

Creation request flow:

1) User triggers POST with longUrl

2) Once the request hits the load-balancer, the request is redirected to one of multiple reverse-proxy servers behind

3) reverse-proxy server would redirect the request to app server based on the traffic to authenticate the user

4) Once the authentication is successful, the creation service will be triggered and shortUrl is generated

5) The generated shortUrl is stored in dB and the same data is replicated in dB replica

Redirection URL flow:

1) User triggers shortUrl

2) Once the request hits the load-balancer, the request is redirected to one of multiple reverse-proxy servers behind

3) reverse-proxy server would redirect the request to app server based on the traffic to authenticate the user

4) Once the authentication is successful, the redirection service is triggered to fetch the associated longUrl

5) the service hits cache for longUrl. If it misses, the service would connect to dB and fetch the data

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

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

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

Future improvements

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