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:

• High Availability: This requirement ensures that the service remains operational and accessible even during failures. For your design, consider implementing redundancy and failover mechanisms to minimize downtime.
• Low Redirect Latency: Users expect quick responses when they click on shortened URLs. Aim for a redirect latency of milliseconds. This can influence your choice of caching strategies and data storage solutions.
• Horizontal Scalability: As your service grows, it should handle increased traffic by adding more servers rather than upgrading existing ones. Design your architecture to support load balancing and partitioning of data to achieve this.
• Traffic Estimation: Understanding the read vs. write ratio and growth projections is crucial. This informs your database design and helps in resource allocation to handle peak loads.
• Storage Estimation: Calculate the expected size of the URL mapping table based on anticipated usage. This will guide your choice of storage technology and indexing strategies.
• Reliability & Fault Tolerance: Identify single points of failure and plan for disaster recovery. This is essential to maintain service continuity.

API Design

API needs to handle two primary functionalities: receiving long URLs to generate short URLs and converting short URLs back to their original long URLs.

• Short URL Creation: When a user submits a long URL to your API, it should generate a unique identifier (short code) and store the mapping of this short code to the long URL in a database. The API then returns the short URL, which typically combines a base URL with the short code.
• URL Resolution: When a user accesses a short URL, the API should extract the short code, look up the corresponding long URL in the database, and redirect the user to that long URL.

High-Level Design

The server providers two endpoints, one to short a URL and one to convert from the short URL to the long URL.

The client communicates with the server, and the server stores the relation short-long URL in the database. The mapping is also stored in the cache database for rapid access with an expiration date of 24 hours.

Detailed Component Design

API Endpoints: Design the URL shortening and redirect endpoints. The shortening endpoint should accept a long URL and return a short URL, while the redirect endpoint should take a short URL and return the corresponding long URL.

Write Path Service: This service handles the creation of short URLs. It should include logic for generating unique identifiers (e.g., using a base62 encoding scheme) and storing the mapping in a database. Consider using a distributed database for scalability.

Read Path Service: This service retrieves the long URL from the short URL. It should be optimized for low latency, possibly utilizing caching mechanisms to speed up frequent lookups.

Data Storage Layer: Define the structure of the URL mapping table, which should include fields for the short URL, long URL, and metadata (like creation date). An index strategy for efficient lookups is crucial.

Caching Layer: Implement a caching mechanism to store frequently accessed short URL mappings, reducing the load on the database and improving response times.

Identifier Generation: Ensure that the ID generation process avoids collisions, is hard to guess, and can handle outages gracefully.

Partitioning Strategy: Choose an effective partition key for your data to ensure even distribution and avoid hotspots, especially during high traffic.