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.)...
• High availability (99.9% uptime)
• Low latency (reads < 10ms via cache)
• Scalability (handle millions of URL creations/day)
• Durability (shortened URLs should never be lost)

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST /shorten

Request: { "longUrl": "https://example.com/very/long" }

Response: { "shortUrl": "https://tinyurl.com/ab3Xy9" }

GET /{shortCode}

Response: 301/302 redirect to longUrl

301 = permanent redirect, browser caches it (less server load)

302 = temporary redirect, hits your server every time (better for analytics)

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.

"Event-driven architecture with separate read and write paths. Write path uses Kafka for async processing into sharded Cassandra. Read path uses Redis cache with consistent hashing fallback to Cassandra on cache miss."

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.

Base62 Encoding:

"Generates a 7 character short code using characters [a-z, A-Z, 0-9] giving 62^7 ≈ 3.5 trillion unique URLs. On collision, append an incrementing counter and re-encode until unique."

Consistent Hashing:

"Uses virtual nodes to evenly distribute keys across Cassandra shards. On read or write, hash(shortCode) determines the clockwise nearest node. Adding/removing nodes only migrates a fraction of keys, avoiding full resharding."