System requirements

Functional:

1. Generate a short url for a long url.
2. When given a long url and return a short url.
3. If we get a duplicate request to generate short url for a long url, we will just return the already generated short url.
4. User must be able to set expiry time on some of the urls.
5. We should provide customizable urls for some companies.
6. We should provide analytics metrics to view the metrics for each api.

Non-Functional:

1. The system should be highly available, we will choose availablilitty over consistency here.
2. Latency overheads should be minimal.
3. We should be having our servers as close to clienrt as we can i.e in every region we must be having our servers.

Capacity estimation

Estimate the scale of the system you are going to design...

1. tps: 100 read tps and 1 write tps.
2. memory estimation: lets asume 300Bytes for one entry, so around 3 GB of data will be generated everyday.

API design

Define what APIs are expected from the system...

only two apis for now

1. getShortUrl(String longUrl, Optional expiry_time, optional customized_prefix_url): generates the short url and returns it.
2. getLongUrl(String shortUrl): gets us the long url with a 302(temporary) and increase its count for the backend, returns an error if the short url is 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...

we are going to use nosql database for this, as our main goal is availability over consistency, also we dont require the complex quries so sql has no major advantage here.

schema:

{

uniqueId: string, (primary key)

shortUrl: string,

longUrl: string,

ttl: timestamp

}

High-level design

the client request first goes to the dns, then it goes to the load balancer, it then goes to the server, which maintains a cache, and a database as the source of truth.

Request flows

For the write flow: for the write we will use write around cache strategy, firstly the request goes to the web server to generate the short url, the server will generate the short url and then puts into the db.

For read flow: we will use read through strategy, the web will ask for the long url, the request will go to the cache, it will check in the cache, if not found, it will check in the db and then populate the cache and return the response.

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?