System requirements

Functional:

1. Create a short URL for the given long URL.
2. Redirect to long URL when the shortened URL is accessed.

Non-Functional:

1. Availability: at least 99.9% uptime.
2. Scalability: auto scaling to handle high traffic as demand grows.
3. Performance: low latency less than 10ms to create and redirect short URL.
4. Durability: persist all short URLs in reliable storage to ensure no data loss.

Capacity estimation

Transactions per Second (TPS)

1. Create short URL: 100 TPS
2. Read and redirect short URL: 1,000 TPS (10 times read operations)

Storage

Assume each URL entry requires approximately 250 bytes.

250 bytes * 100 TPS * 86,400 seconds/day ~= 250 * 100 * 100,000 ~= 2,500,000,000 bytes/day

The daily new storage requirement is roughly 2.5GB data.

API design

Create short URL

• Endpoint: /api/shorten
• Method: POST
• Description: create a shortened URL for the given long URL

Request (JSON)

Response (JSON)

Read long URL

• Endpoint: /api/lookup
• Method: POST
• Description: gets the original long URL associated with a given short URL.

Request (JSON)

Response (JSON)

Database design

Use key value store to persist data (e.g., AWS DynamoDB). Here is the table design.

• Table name: URLMapping
• Columns:
  • short_url: primary index for quick lookup
  • long_url: original long URL and secondary index to check if long URL already exists
  • created_at: timestamp
  • expiration_date: auto cleanup
  • user_id: track who created this long and short url association

High-level design

• User: The individual interacting with the URL shortening service via a web interface or mobile application.
• Frontend Web UI & Mobile App: Interfaces that facilitate user engagement in creating or accessing short URLs through API requests.
• API Gateway: Acts as the central point of entry for all API calls. It manages request forwarding, load balancing, and authentication, while also providing DDoS protection.
• URL Shortening Service: The main logic processor responsible for handling URL shortening, redirection, and data analytics.
• Firestore URL Mapping: A database that stores the relationship between short URLs and their corresponding long URLs.
• Analytics DB: An optional database used for tracking metrics such as the number of accesses, geolocation of users, and other analytics data.
• Cache Layer: An intermediary storage layer (e.g., Redis) that holds frequently accessed URL mappings in memory. This significantly speeds up retrieval times for short URLs, reducing database load.
• CDN (Content Delivery Network): Caches content at various locations closer to users to serve short URLs rapidly. It can help balance loads by distributing requests across several servers and can return short URL data to the API Gateway without hitting the core backend services.

Request flows

1. Create Short URL Flow:
   • The user submits a long URL through the web UI or mobile app.
   • A request is sent to the API Gateway.
   • The API Gateway forwards the request to the URL Shortening Service.
   • The service saves the mapping of the long URL to the generated short URL in Firestore.
   • The generated short URL is also cached in the cache layer to improve future retrieval speeds.
   • Finally, the short URL is sent back to the user.
2. Redirect to Long URL Flow:
   • The user accesses a short URL.
   • This initiates an API request to the API Gateway.
   • The gateway first checks the cache for the mapping.
   • If there is a cache hit, the user is redirected immediately.
   • If there is a cache miss, the API Gateway forwards the request to the URL Shortening Service.
   • The service retrieves the original long URL from Firestore and returns it.
   • The user is then redirected to the original long URL.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?