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.)...
• How short shoud a short url be?
• How many urls do we espect?
• 300 ms letency
• 1000 request max per second
• deplot to another server in case of to many request
• consistency>availability

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 /api/shorten

{ "longUrl": "https://www.example.com/some/very/long/url", "customAlias": "mycustomurl"}

respone {

{ "shortUrl": "https://short.ly/mycustomurl", "longUrl": "https://www.example.com/some/very/long/url"}

}

get api/shorten/{shprturl}

respone{longUrl": "https://www.example.com/some/very/long/url",

}

Get short url, send back a long url

High-Level Design

In the high-level design, you focus on the main components of the system and how they interact with each other. Here’s an example:

1. Client Layer: Users interact with the service through a web or mobile application.
2. API Gateway: This layer handles incoming requests, routing them to the appropriate services (e.g., URL creation, redirection).
3. Write Path Service: Responsible for taking long URLs, generating short URLs, and storing them in the database.
4. Read Path Service: Handles requests for short URLs, retrieves the corresponding long URL from the database, and redirects users.
5. Database: A persistent storage layer where mappings between short and long URLs are stored.
6. Caching Layer: To improve performance, frequently accessed short URL mappings can be cached.
7. Analytics Service: Collects data on URL usage (e.g., number of clicks) for reporting and insight

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.

Overview

The Write Path Service is responsible for creating short URLs from long URLs. It handles the validation of incoming URLs, generates unique short URLs, and stores the mapping in the database.

Responsibilities

1. Validate Long URL: Ensure that the provided long URL is well-formed and reachable.
2. Generate Short URL: Create a unique short URL using a hashing algorithm or a sequential ID generator.
3. Store Mapping: Save the mapping of the short URL to the long URL in the database.
4. Return Short URL: Provide the generated short URL back to the client.

API Endpoints

• Endpoint: POST /api/shorten
  • Request Body:
  • { "longUrl": "https://www.example.com/some/very/long/url"}
  • Response:
  • { "shortUrl": "https://short.ly/abc123"}

Workflow

1. Receive Request: The service receives a request to shorten a URL.
2. Validate URL:
   • Check if the long URL is valid (e.g., proper format, reachable).
   • Return an error response if validation fails.
3. Generate Short URL:
   • Use a hash function or a sequential ID generator to create a unique short URL.
   • Ensure that the generated short URL does not already exist in the database.
4. Store Mapping:
   • Save the mapping of the short URL to the long URL in the database.
   • Optionally, store additional metadata (e.g., creation timestamp, user ID).
5. Return Response: Send the generated short URL back to the client.

Error Handling

• Duplicate Short URL: If a generated short URL already exists, retry generating a new one.
• Database Errors: Handle any database errors gracefully and return appropriate error messages to the client.

Performance Considerations

• Caching: Frequently accessed mappings can be cached to reduce database load.
• Rate Limiting: Implement rate limiting to prevent abuse (e.g., too many URL shortening requests from the same IP).

the read path

Recive request , validate short url and check aganst cahe, and it add to the cache if iits found in dbsomethign its return if not will retarn a 404