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.)...

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

2 API Path is sufficient I guess if we just want to build user facing type of app.

1. POST /v1/url (responsible to short the long URL)
2. GET /v1/url/:short_url (redirect the short url to long url)

High-Level Design

When request come, it will be handled/routed by NGINX or load balancer that will decide which service will handle it. After that the chosen service will response based on the logic reside on the API.

Creation API

• Validation
• Insert the entity to database to get incremental ID (with assumption ID is auto increment)
• base62 encode the ID to get the short_url (since the ID is auto increment therefore its the encoded will always be unique)
• Update the entity
• Wrapped all write query in a single transaction

Redirection API

• Check if its exist on cache, if yes do redirect
• If not exist on cache, check if its exist on database, if not exist then response not found.
• If exist on database, cache the long url with cache key entity id or short url (with no expire, since there's no way we could update the short url based on the requirement) and then redirect.

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.