Requirements

Functional Requirements:

• User will provide the long URL and it will be converted to short URL
• At the same, when user provides a short URL, it should be converted back to long url

Non-Functional Requirements:

• The long URL to short one should be completed below 1 second.
• Read heavy operation where 100 millions reads can happen and 10 million writes can happen.
• Services should be up and running always. There should be minimal downtime (99% should be up).

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

API to create the short url

/api/v1/url

{

long_url:

}

response:

{

short_url:

}

/:slug

response

{

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

API Gateway will handle all the API requests which includes short url creation or long url read.

Shortener Service --> Create a short url hash and save it in the DB

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.

User will send the request to create the short url and it will go to the API gateways.

It automatically redirects to the shortener service where it creates the shorten URL and will save it in databases.

Additionally, we will have another reader services which will go look for the value in cache first and then read from the DB on cache miss.

To provide better reliability, our services will be running in microservices architecture which ensures the availability of the services.

Additionally, DB services will be replicated with HA, so DB is not a single point of failure.

Cache will be used for faster read operation that reduces the latency to 10ms