Requirements

Functional Requirements:

• The service shows a field input for the user.
• System validate the url and calls the shortening service
• The service must store each original url and it's new url.

Non-Functional Requirements:

• The service loads under 200ms
• The input is sanitized for malicious strings
• The service only accepts strings.
• The shortening service must take no more then 200ms load time

Capacity Estimation

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

System is expected to have 1000 daily active user, 30000 monthly active users.

with read/write ratio of 5/2

Read operations will be used mainly when a user click on a shortened url, system will need perform a read operation for the original url.

Write Operations when the user request the shortening service.

bandwith i dont know how to calculate it

API Design

POST /urls/create, body {originalUrl:""}, response {original URL, shortened url, id}

GET /urls/id, => response {original URL, shortened url, id}

get /urls => response [{original URL, shortened url, id}]

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.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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.