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:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

This system requries , low latency : sharding , key value pairs ,and load balancers help in that ,

Isolating the server and the database also helps in that , for datbase mongodb ( no sql , key value , document pair is also better )

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

@post_url(): which the user will use to post a long url (get request) , @access_db() -- > we use it to access database from the server for the key value pair @send_short(): we will send the actual key to user ( post request) .

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.

the major problem arises when a lot of users use the same thing , for that we can use a load balancer and use more servers , sharding will also work here

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.

For a simple url shortener a simple idea is basically the client sends in a get post request to first create a short link Api called def_shortner(): will take that url , convert it into a short url ( whatever logic it uses , and svaes it as a key value pair in the database) , whenever a user fetches the data we will fetch it from the database using @def fetch , to scale it , and lower costs , we can add in specific hash at the end , which will add in lowering latency for the server to fetch , we can use sharding to do that as well