1. Introduction

TinyURL is a URL shortening service that converts long URLs into short, easy-to-share links. It should be scalable, efficient, and highly available to handle millions of URL redirections.

 


2. System Requirements

2.1 Functional Requirements

  • Shorten a URL – Users can input a long URL and receive a shortened version.
  • Redirect to Long URL – When accessing a short URL, the system redirects to the original long URL.
  • Custom Short URLs (Optional) – Users can provide a custom alias instead of a random string.
  • Expiration Support – URLs can have an expiry date (optional).
  • Analytics (Optional) – Track clicks, geo-location, and referrer data.

2.2 Non-Functional Requirements

  • High Availability – The system should be available 24/7.
  • Low Latency – Short URL lookups should be fast (<10ms).
  • Scalability – Handle millions of URL shortenings and redirections.
  • Security – Prevent abuse (spam, phishing, brute-force attacks).
  • Consistency – Ensure users always get the correct long URL.

3. High-Level Architecture

  • Client Layer – Web, Mobile, API Clients
  • Load Balancer – Distributes traffic across multiple servers
  • Application Layer – Handles URL shortening, retrieval, and analytics
  • Cache (Redis/Memcached) – Caches frequently accessed URLs
  • Database (SQL/NoSQL) – Stores URL mappings
  • Analytics System (Optional) – Collects user click data

4. Component Breakdown

4.1 API Gateway

  • Exposes RESTful APIs for clients (web/mobile).
  • Handles authentication and rate limiting.

4.2 URL Shortening Service

  • Generates a unique short URL for each long URL.
  • Stores the mapping in a database.

4.3 Redirection Service

  • Fetches the long URL from storage.
  • Redirects the user to the original URL.
  • Logs analytics (if enabled).

4.4 Database Layer

  • SQL (MySQL/PostgreSQL): Good for relational data and indexing.
  • NoSQL (DynamoDB, Cassandra, MongoDB): Better for high scalability.

4.5 Caching Layer (Redis/Memcached)

  • Stores frequently accessed URLs to reduce DB calls.


4.6 Analytics Service (Optional)
  • Stores click events (timestamp, IP, referrer, device).
  • Provides reports and dashboards.

5. URL Generation Logic
  • A short URL is typically a 6-10 character alphanumeric string.
  • Example:
 
Original URL: https://www.example.com/this-is-a-very-long-url
Shortened: https://tinyurl.com/XyZ123

  • Encoding Methods:
    Base62 Encoding – Converts a unique ID into a string of [0-9A-Za-z].
    Hashing (MD5/SHA-256) – Generates a fixed-length identifier.
    Collision Handling – Retry with a new string if a collision occurs.


6. Scaling Considerations

  • Database Sharding – Distribute URLs across multiple DB servers.
  • CDN for Faster Access – Use Cloudflare or AWS CloudFront.
  • Load Balancers – Distribute traffic across multiple app instances.
  • Replication – Use database replicas for read-heavy operations.
  • Asynchronous Processing – Queue analytics logging instead of blocking requests.

7. Security Measures
  • Rate Limiting – Prevent abuse of the URL shortening API.
  • Blacklist – Block malicious/phishing URLs.
  • Token-based Authentication – Secure API access.
  • SSL/TLS Encryption – Protect data in transit.

8. System APIs

8.1 Shorten URL API

POST /shorten
{
"long_url": "https://www.example.com/long-url",
"custom_alias": "myShortUrl" (optional),
"expiry_date": "2025-01-01T00:00:00Z" (optional)
}

Response:
 
{
"short_url": "https://tinyurl.com/XyZ123"
}

8.2 Redirect API
 
GET /XyZ123

Response:

  • 302 Redirect to long URL.


8.3 Analytics API (Optional)
 
GET /analytics/XyZ123

Response:
{
"clicks": 1023,
"geo_distribution": { "USA": 50%, "India": 30%, "Others": 20% },
"top_referrers": ["facebook.com", "twitter.com"]
}

9. Capacity Estimations

  • 50M new URLs/month → 600M URLs/year
  • Each short URL needs 7 bytes (Base62 encoding).
  • Storage Needs: ~ 10-20TB for 5 years.
  • 10K requests/sec capacity for global scaling.

10. Summary

TinyURL is a high-performance, distributed system for URL shortening.
Caching, database sharding, and load balancing ensure scalability.
Security measures protect against spam and abuse.

PreviousNext