Design a URL Shortener (TinyURL) 🔗

A URL shortening service converts long URLs into short, unique links for easy sharing and tracking.

🚀 Introduction

TinyURL is a classic system design problem that touches on scalability, hashing, and high-availability redirection.

• Example: https://example.com/very/long/path → https://tinyurl.com/abc123
• Key Benefits: Compact links for social media, improved UX, click tracking, and branding opportunities.

How it Works

1. User submits a long URL.
2. System generates a unique short key.
3. Stores the mapping in a durable database.
4. Redirects any requests to the short URL back to the original.

📋 Requirements

Building a system at scale requires a clear understanding of what we are optimizing for.

Functional Requirements

• Shorten a URL: Accept a long URL and return a unique short key.
• Redirect: Accessing the short URL must redirect (301/302) to the original URL.
• Prevent Duplicates: Return the same short key if the long URL was previously shortened.
• User Features: Authentication for managing links, custom aliases, and viewing analytics.

Non-Functional Requirements

• High Availability: >99.9% uptime (Critical for redirection).
• Sub-millisecond Latency: Redirection must be near-instantaneous for a smooth user experience.
• Scalability: Support billions of URLs and high read throughput (Read-Heavy).
• Durability: Ensure data persistence with backups to prevent mapping loss.

🛠️ API Design

Clear, well-defined endpoints are the backbone of service communication.

1. Create Short URL

Accepts a long URL and returns a shortened URL.

• Endpoint: POST /api/shorten
• Request (JSON):

{
  "long_url": "https://www.example.com/article?id=123"
}

• Response (JSON):

{
  "short_url": "https://tinyurl.com/abc123"
}

2. Redirect to Original

The core functional requirement for the service.

• Endpoint: GET /:short_key
• Behavior: Looks up the original long URL and returns a 302 Found (Temporary Redirect) to preserve analytics.

3. Delete Short URL

• Endpoint: DELETE /api/url/:short_key
• Behavior: Deletes the mapping if the user is authenticated and owns the URL. Requires a Bearer token.

🔐 User Authentication APIs

To provide personalized features like analytics and custom aliases, we need secure auth endpoints.

• URL Registration: POST /api/auth/register
• User Login: POST /api/auth/login
• Authorization: Secure endpoints are protected with a Bearer: <access_token> header using JWTs.

🔑 URL Generation Strategies

How do we generate that "short key" without collisions in a distributed system?

🏗️ The Final Design - TinyURL

The final architecture separates URL generation from redirection and includes a dedicated User Management service for authentication and personalized settings.

📊 Scale Estimation & Bottlenecks

Traffic Projections

• DAU: ~10 Million
• New URLs/day: ~100,000
• Redirects/day: ~50 Million (Read-heavy)

🛠️ Bottleneck Identification

1. High Read Volume: Focus on Caching and low-latency database reads using indexes on the short_key.
2. Write Throughput: While write volume is moderate, ensure acid consistency for new URL mappings.
3. Burst Traffic: Plan for sudden spikes using Autoscaling Groups and potentially a CDN for frequently accessed links.

💡 Top Interview Questions