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

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

User count: 100M users/day

per user: 100 reads per write -> read heavy

no account storage, lets assume 24 hour lifetime for each URL

avg URL: 100 bytes

so total daily data movement for URLs: 100 B * 100M = 10^10 B, or 10 GB

api/getShortUrl -> user provides a long url and receives an encoded URL

• PUT request: create a new encoding in the database
• response with the long URL

api/getLongUrl?code -> user hits an encoded URL and the system decodes the Short url into the original long url

• GET request: get the short URL from the CDN or the database

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.

Use blob storage S3 to store the long Urls, and we would want to cache the decoded urls on getLongUrl in some sort of CDN.

we would also want to create the urls using base62 encoding and we can generate them in a KGS to ensure uniqueness. use a redis list and LPOP.

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.