Requirements

Functional Requirements:

1. Create short URL - given a long URL, generate a unique short alias
2. Redirect - given a short URL, return the original long URL and redirect the user
3. Custom alias - allow users to pick a readable alias
4. Expiration - support optional TTL so links expire
5. Delete/update - let the owner remove or repoint a short link
6. Analytics - track click counts per short URL

Non-Functional Requirements:

1. High availability - the redirect must never fail even if a server dies
2. Low redirect latency - sub-100ms; the write path can be slower, the read path must be fast
3. Horizontal scalability - handle millions of reads/day by adding more servers

Capacity Estimation

• 100M new URLs/day (writes)
• Read:write ratio = 100:1 (typical for URL shorteners)
• Long URL ≈ 500 bytes avg; each DB record ≈ 1KB with metadata

Traffic / QPS

• Writes: 100M / 86400 = 1158 w/s
• Reads: 115741 r/s
• Peak: 348K r/s

Storage

• 100M * 1KB = 100 GB/day
• 5-year retention: 100 GB * 365 * 5 = 180TB

Cache

• Cache hot URLS: 20M * 500B = 10GB

API Design

POST /api/urls

Request:

{

"longUrl" : "string (required)",

"customAlias" : "string (optional)",

"expiresAt" : "datetime (optional)"

}

Response: 201 -> {"shortUrl"}

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.