Design a Distributed URL Shortener (TinyURL)

1. Problem Statement & Scope

System Mission

Design a highly scalable, fault-tolerant, low-latency URL Shortening service (similar to TinyURL or Bitly) that transforms long HTTP URLs into compact 7-character aliases, handles billions of redirects with sub-10ms latency, supports custom aliases, expiration TTLs, and real-time click analytics.

Functional Requirements

1. URL Shortening (POST /v1/urls): Given a long URL, generate a compact, unique 7-character alias (e.g. https://hi.link/aZ9k2Lq).
2. URL Redirection (GET /{short_code}): Given a short code, instantly redirect the client to the original long URL with minimum latency.
3. Custom Aliases & Expiration: Allow users to specify custom short aliases (e.g. https://hi.link/summit2026) and optional expiration timestamps (TTL).
4. Click Analytics: Asynchronously aggregate click metrics (total clicks, referrer, client country, timestamp).

Non-Functional Requirements (SLAs/SLOs)

• High Availability: $99.999\%$ uptime SLA for redirection lookups (Read Path is mission-critical).
• Ultra-Low Latency: P99 Read Redirection Latency $< 10\text{ ms}$; P99 Write Latency $< 50\text{ ms}$.
• Durability: $99.999999999\%$ (11 9s) zero URL mapping loss guarantee.
• Read-to-Write Ratio: Heavy read bias of $100:1$ (100 redirections per 1 new URL shortened).

2. Capacity & Scale Estimation

Traffic Calculations

• New URL Creation Rate (Writes):
  • 100 Million new URLs created per month.
  • Average Write QPS: $\text{Write QPS} = \frac{100,000,000}{30 \times 86,400} \approx \mathbf{38.6\text{ writes/sec}}$
  • Peak Write QPS ($5\times$ burst): $\mathbf{200\text{ writes/sec}}$.
• Redirection Traffic (Reads at 100:1 Ratio):
  • Average Read QPS: $\text{Read QPS} = 38.6 \times 100 \approx \mathbf{3,860\text{ reads/sec}}$
  • Peak Read QPS ($3\times$ burst): $\mathbf{11,580\text{ reads/sec}} \approx \mathbf{12,000\text{ QPS}}$.

Storage & Memory Estimation (10-Year Horizon)

• 10-Year URL Volume: $100\text{M URLs/month} \times 12\text{ months} \times 10\text{ years} = \mathbf{12\text{ Billion URLs}}$
• Record Size:
  • short_code: 7 Bytes.
  • long_url: 500 Bytes average.
  • user_id: 16 Bytes.
  • created_at / expires_at: 16 Bytes.
  • Metadata & Overhead: 61 Bytes.
  • Total per Record: $\approx 600\text{ Bytes}$.
• 10-Year Database Storage: $12 \times 10^9 \times 600\text{ Bytes} = \mathbf{7.2\text{ TB}}$
• 3-AZ Multi-Region Replicated Storage: $7.2\text{ TB} \times 3 = \mathbf{21.6\text{ TB}}$
• In-Memory Cache Sizing (80/20 Pareto Rule):
  • Daily active redirection requests: $3,860 \times 86,400 \approx 333\text{ Million requests/day}$.
  • $20\%$ hot URLs generate $80\%$ of traffic: $\text{Daily Unique Hot URLs} = 333\text{M} \times 0.20 \times 600\text{ Bytes} \approx \mathbf{40\text{ GB RAM}}$
  • Allocate an Amazon ElastiCache Redis Cluster with $64\text{ GB RAM}$ (easily caching 100% of daily hot URLs).

Base62 Encoding & Hash Space Math

A short code consisting of alphanumeric characters [0-9, a-z, A-Z] has a character alphabet size of: $\text{Base} = 10 + 26 + 26 = 62$ For a 7-character string, the total unique URL capacity is: $62^7 = \mathbf{3,521,614,606,208} \approx \mathbf{3.52\text{ Trillion unique URLs}}$ At $100\text{M}$ URLs/month, $3.52\text{ Trillion}$ provides over 2,900 years of collision-free namespace capacity.

3. AWS-First High-Level Architecture

Interactive Architecture Diagram
100%Fit100%
Synthesizing vector architecture diagram...