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

1. Create Short URL: POST /shorten which created a shortened URL from a long URL

Request:

{ "long_url": "https://www.example.com/very/long/url/here", "custom_alias": "myalias" // optional}

Response (201 Created):

{ "short_url": "http://tinyurl.com/abc123", "long_url": "https://www.example.com/very/long/url/here", "created_at": "2024-01-15T10:30:00Z"}

2. Redirect to Original URL

GET /{short_key}

Redirects the user to the original long URL. Returns a 301 (permanent redirect) — good for SEO/caching, or 302 (temporary) if you want to track analytics per click.

Response (301/302):

Location: https://www.example.com/very/long/url/here

3. Delete Short URL

DELETE /{short_key}

Removes a short URL. Requires auth.

Response: 204 No Content

High-Level Design

1. Client → DNS → CDN → Load Balancer → API Gateway (Entry Layer)

• Load Balancer distributes traffic across service instances
• API Gateway handles SSL termination, rate limiting, and routing

2. Write Path — Shortener Service

• Handles POST /shorten requests
• Takes the long URL, calls the ID Generator for a unique key, stores the mapping in the database
• Returns the short URL to the client

3. Read Path — Redirect Service

• Handles GET /{short_key} requests
• First checks the Cache (Redis) — cache hit = immediate redirect
• Cache miss → queries the Database, populates cache, issues redirect
• Returns 301/302 with Location header

4. ID Generation Service

• Generates unique, collision-free short keys (e.g., base62 encoding of a unique integer)
• Could use a distributed ID generator (Snowflake-style) or a DB-backed counter

5. Caching Layer (Redis)

• Stores hot short key → long URL mappings
• Reduces latency on reads (avoids DB queries) — critical for the 3,800 reads/sec

6. Database (Storage Layer)

• Stores the mapping: short_key → long_url, created_at, expiry
• Needs fast lookup by short key (primary key)

flowchart TD Client[User / Browser] DNS[DNS] CDN[CDN] LB[Load Balancer] GW[API Gateway] subgraph Write[Write Path] Svc[Shortener Service] IDGen[ID Generator] end subgraph Read[Read Path] Redirect[Redirect Service] Cache[(Redis Cache)] end DB[(Database)] Client --> DNS --> CDN --> LB --> GW GW -->|POST /shorten| Svc Svc --> IDGen Svc --> DB GW -->|GET /{key}| Redirect Redirect --> Cache Cache -->|miss| Redirect Redirect --> DB DB --> Redirect Redirect -->|30

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.