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:

• low latency
• performance (throughput, resource utilization)
• scalability
• reliability
• security
• observability

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

CreateShortURL(url) -> short_url

GetURL(short_url) -> url

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.

Let us first describe the components in the system:

• We have a cluster of stateless servers.
• We have a load balancer.
• We have a single write database.
• We have multiple read databases.

The client sends a request to our endpoint, whether it's the create short URL request or get URL request, and its request is received by a load balancer that decides which server to direct their request to. The request is received by one of our stateless servers, which has very simple logic. For the create short URL request, the service creates one by some logic, and then it sends a write request to the write database. Then the write database periodically writes. It can be Redis, for example, or, in other words, a key-value map or NoSQL database. Our write database will write the result, the mapping between the long URL and the short URL, to all of the read databases with eventual consistency. Going back to our server, if it receives a GET URL request, then it will send a read request to one of the read databases. It should get the result and return it to the user.

The reason we have this set up is that we want multiple instances of the read database to allow a high throughput and low latency, because we are expected to receive thousands of GET URL requests per second. On the other hand, the number of create URL requests per second should be much lower, and therefore we don't need more than one write database there. The trade-off here is that we have eventual consistency, which means it will take some time until the write database writes to all of the read databases, but it's a trade-off we're willing to take.

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.