Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• Check char Len for actual url

Non-Functional Requirements:

• Consistency (No same tiny url for two different long urls)
• Scalable if millions of user paste urls at the same time
• Low Latency for redirecting tiny urls to actual urls
• Durable mapping for url <> tinyUrl

API Design

POST: /to-tiny-url

Body: {

url: ${original_url}

}

*****PREVALIDATION*****

Check len(url) <= charLen

*************************

POST: /to-long-url

Body: {

url: ${tiny_url}

}

*****POST-VALIDATION*****

Check len(url) <= charLen

*************************

Entity:

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

1. CLIENT sends request to Tiny Url Service
2. Api gateway serves as a middleware to rate limit, url validation, and routing
3. Api gateway sends request to load balancer and load balancer manages traffic to serve the request via "Tiny Url Service"
4. Since multiple users can request to transform same url to tiny url, it makes sense to have Redis as a Cache Aside to serve the request
5. We use Postgres Database for consistency mapping with long url and tiny url.
6. Also each tiny url as a Time to Live based on user requirement so the tiny url does not remain stagnant as that url could be used to serve different url

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.