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:

• 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

Response:

8.2 Redirect API

Response:

• 302 Redirect to long URL.

8.3 Analytics API (Optional)

Response:

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.