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:

• Low latency on retrieval

API Design

Write path:

• Client sends HTTP POST request to admin.domain/api/urls
• Request contains JSON with at least url parameter. There also could be store some time-to-live parameter in the future.
• As a response there could be returned JSON with "shortened-url" parameter.

Read path:

• Client sends HTTP GET request to shrt.domain/<hash> The response should return 404 if hash is invalid (nonexisting/deactivated) or 302 with Location header containing original URL

High-Level Design

There are two separated servers:

1. The "backoffice" service to administrate - creating and deleting.
2. The "retrieval" service to access shortend urls.

Both services access the database, that contains entries with shortend and original urls. The database.

Detailed Component Design

The backoffice and retrieval services are stateless, so they can scale separately. The most critical is database. It can be some relational database replicated multiple times. The database also can use sharding to improve scalability.

To assure low latency on url retrieval, shortened url needs to be propagated on multiple database replicas. To achieve that, the master database instance that handles writes, the creating operation needs to assure, that all data are synced to replicas - then it can return response with new entry.

Master database also is responsible for generation next shortened url.