System requirements

Functional:

1. Ability to take the URL and return a shorter format of URL

Non-Functional:

1. Consistency -> We want the service to be available over consistency
2. Low latency.
3. Be available in multiple region of the world

Capacity estimation

1. We want to support 100 reads per second and 1 write per second
2. 1 write per second, we have 60 * 60 * 24 second per day, we assume 8 bytes of data per URL, totally 800 MB per day
3. WIth 100 reads per second, we can't get it from just one machine, I think we would need to scale beyond that

API design

2 API

1. read short-url.com/<url-link-short>

This API would redirect the user to actual resource and return 302 (redirected) when success and 404 if fail

1. write api let the user encode their URL through UI portal. We will allow them specify URL themselves (which internally would be translated into a hash can be easily to locate the node)

We may also want to ensure that the link encoded aren't malicious or point to dark web/denied resource. If a user tries to encode like that, we may deny the creating request

Database design

The design is straight forward, a simple (persistent) key-value store.

Since key-value stores are usually NoSQL, we don't have to worry about the scaling issue too much here

High-level design

We are going to have a design where a client would hit the load balancer which would redirect our request to the appropriate application server based on the RR stateless algorithm.

The application server would first check if the url in our in memory cache(which we would know based on the cache server id and the cache is LRU)

if we get he hit, we return right here. Else we would want to check out the database NoSQL database would be able to route the request to the correct partition and return the request. if no present, return 404

Overall, I am ok if immediately after the resource is added, it takes a while for it to be fully propagated to all replicas (eventually consistency is OK). However, we do want to keep durability (making sure we don't lose the write request) and latency(make redict as quickly as possible < 20ms)

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

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?