Requirements

Functional Requirements:

User should be able to write a full URL and receive a short alias

User should be able to request the short alias and get the original full URL

Non-Functional Requirements:

Handle ~100:1 read-to-write ratio

Rate limiting to combat spamming

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

POST /v1/urls

{

"text" : url

} -> response : {"text": alias}

GET /v1/urls/alias -> url

DELETE /v1/urls/alias

High-Level Design

The main component would be a urlMap that maps aliases to full URLs. We're going to declare users and authentication as out of scope for the initial design. In this sense we can have a simple monolithic architecture with just one HTTP server that handles the API endpoints, writes/reads from the database, and sends responses back to the client. We could also add a rate limiter between the client and server so that spam attacks won't cause a DoS for legitamate requests.

Database Design

Detailed Component Design

The server could use a hash alogorithm to generate hashs that can be used for the shorten url, similar to TinyURL.