Requirements

Functional Requirements:

• Create short URL: Users submit a long URL and receive a short unique alias (e.g., tinyurl.com/abc123)
• Redirect: Visiting a short URL redirects the user back to the original long URL via HTTP 301 or 302
• Custom Alias (optional): Users can optionally specify a custom short path
• Expiration (optional): Short URLs can optionally expire after a set time

Non-Functional Requirements:

• High Availability (critical): the redirect path must remain operational even during failures. Short links can be shared aynwhere - a 503 means a broken link for potentially millions of users
• Low redirect latency (latency): redirects must complete within a few hundred milliseconds. Users expect instant navigation.
• Horizontal scalability: The system must scale out to handle traffic spikes from viral links
• Durability: Once created, a short URL should not be lost

Capacity Estimation

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

Traffic Estimation: assume 100 million URLs created per month and read-to-write ratio of 100:1

• URLs created per day: 100 M / 30 ~3.3M/day
• Redirects per day: 3.3M * 100 = 330 M/ day
• QPS (writes): 3.3 M / (24 * 60 * 60) = 38 writes/sec
• QPS (reads): 330 M / (24 * 60 * 60) = 3,800 reads /sec

Storage Estimation:

• short key (6-7 chars): ~7 bytes
• Original URL (200 chars) ~ 200 bytes
• Created_at, user_id, expiry, etc: ~50 bytes
• Total per entry ~300 bytes

Storage Needed:

• 1 year: 100M URLs/month * 12 * 300 bytes ~ 360 GB
• 5 years: ~1.8 TB

Bandwidth:

• Writes in: 38 writes/s * 300 bytes = 11 KB/s
• Reads out: 3,800 reads/s * 200 bytes (original URL) = 760 KB/s

API Design

APIs:

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.