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.)...
• The short url to long URL mapping should always be consistent across nodes. we will prioritise consistency over availability
• the url generation can be low latency but not very low latency can take 500ms, not needed to be very fast

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/convert/{url}

GET /v1/{url}

POST {

url

timestamp

}

High-Level Design

• Client who connects to the web-server via a web-browser
• API Gateway to do SSL termination and load balancing of the traffic
• server where the app is running
• a database to store the url mappings

Database Design

Database can be a TTL based NoSQL database

Justification:

• a single write and multiple reads needed.
• complex schema not needed, no joins, foreign keys etc.
• TTL based deletion of URLs can be done, so not persistent storage needed.
• Database fields can be baseurl, shortened_url, creation_dateTime

Detailed Component Design

1 - Main Application that handles the client API requests

2 - A seperate hashing service that converts any given URL into a unique hash, prefixed by a static string like (tinyurl.)

3 - A Cache layer with a TTL based eviction for faster Reads as this is a read-heavy application

4 - A database with a 15 day TTL based eviction for any URL that was created using our service.

4 -