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:

1. Availability over consistency -> We want the service to be available over consistency.
2. Low latency. We want our tiny URL to provide as minimum overhead as possible.
3. Be available in multiple regions of the world

Capacity estimation

1. We can see that we are going to get about 100 reads per second and maybe as much as 1 write per second
2. If we have 1 read per second, to encode a URL we would probably need 8 bytes of data, assuming there is about 10 * 10 ^5 seconds in a day, we get about 8 * 10 ^ 5 Bytes of data a day which is 800 MB of data every day.
3. With 100 reads per second, we can't get away with having everything one host, I think we would need to scale beyond that

API Design

We would want to have 2 types of APIs - one APi would be serving the get request and the URL would look something like this:

co.me/url-link-short.

This API would redirect the sender to the actual resource and on success return 302 (redirected) and on fail we can return something like 404

The other API would to let the user encode their URL through the UI portal. We may allow them specify the URL themselves (which internally would be translated into a hash that can be easily used to locate the node with the the link on it.

We may also want to ensure that the links ecnoded aren't malicious or point to dark web/denied reosuces. If a user tries to encode something like that, we may deny the request on create API flow.

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.

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.