API Design

1. Short URL Creation API

POST /api/shorten

Request Body

{

"longUrl": "https://example.com/page",

"expirationTime": "2026-04-12T00:00:00Z"

}

Response

HTTP/1.1 201 Created

Response Body

{

"shortUrl": "https://short.ly/ab12",

"expirationTime": "2026-04-12T00:00:00Z"

}

2. Redirect API

GET /{shortCode}

Example

GET /ab12

Response

HTTP/1.1 302 Found

Location: https://example.com/page

The browser automatically redirects to the URL specified in the Location header.

Explanation:

The redirect API returns HTTP 302 with the Location header containing the original URL.

The browser automatically redirects the user to that URL.

Returns a 302 (Found) response with the Location header set to the original long URL. The browser follows the redirect automatically. No authentication required. Anyone with the short URL can follow it. This is intentional. Short URLs are shared publicly and must work for everyone who clicks them.

If the short code does not exist or has expired, it returns 404 (Not Found) with a JSON body explaining the error. For expired links, include a message indicating the link has expired rather than simply saying "not found." This helps users understand what happened and reduces confusion.

Rate Limiting:

We need to add rate limiting to prevent any malicious URL from a single client from overloading the system with too many requests within a specific time window. Also, block that user from creating too many URLs. Also, rate limiting stops multiple URL creations from the same client by restricting how many times a client can call the URL creation API within a time window.

Database Design:

Database Choice: NoSQL Key-Value Store (e.g., DynamoDB / Cosmos DB)

We will use a key-value NoSQL database.

Reason:

The system primarily stores a simple mapping between short URLs and long URLs (short_code → long_url). The access pattern is a direct key-based lookup, and there is no requirement for joins or complex relational queries. Therefore, a relational database is not necessary.

The system is highly read-heavy and needs to handle high throughput (20K+ requests per second, and even higher during peak traffic). A NoSQL database is better suited for such workloads.

Additionally, the system will store a large volume of data over time, requiring horizontal scalability. We need features such as auto-scaling, partitioning, high availability, and fault tolerance without significant manual intervention.

Managed NoSQL databases like Amazon DynamoDB or Azure Cosmos DB provide these capabilities out of the box, including automatic scaling, built-in replication, and low-latency key-value access.

Hence, a distributed NoSQL database is the most suitable choice for this system.

Why not PostgreSQL:

PostgreSQL is a relational database and works well for structured data with complex relationships. However, in this system, the workload is highly read-heavy and primarily consists of simple key-value lookups (short_code → long_url), without the need for joins or complex queries.

At the given scale (tens of thousands of reads per second and billions of records), PostgreSQL would require significant manual effort to scale horizontally. This includes implementing sharding, managing partitions, handling replication, and ensuring high availability, which increases operational complexity.

In contrast, a distributed NoSQL database provides built-in horizontal scalability, high availability, and efficient key-based access with minimal operational overhead, making it a better fit for this use case.

Schema:

Table -> URLMapping

Primary_Key:

short_url (Partition Key)

Attributes:

long_url (string)

created_at (timestamp)

expiration_at (timestamp)

click_count (number)

user_id (string, optional)

Submissions

Displaying Solutions with Scores Ranging from 1 to 10