System Design

Introduction # As part of this post, we’ll be covering the design of a modern, highly available, and scalable URL shortening service like TinyURL or Bit.ly. 1. Requirements # Functional Requirements # Shorten - Given a long URL, generate a unique, short alias (e.g. https://tny.li/abc123). Redirect - Given a short URL, redirect the user to the original long URL with minimal latency. Custom Aliases - Allow users to pick a custom human-readable alias (e.g. tny.li/my-resume). Link Expiration - Support optional TTL (Time to Live) on links. Analytics - Track per-link click counts, device types, referrers, and geographic distribution. Non-Functional Requirements # Low Latency - Redirects must be served in < 10ms at the P99 level. Reads far outnumber writes. High Availability - The redirect path is the core business operation. Any downtime directly impacts every shortened link on the internet that points to us. Target 99.99% availability. Scalability - The system should sustain 100K+ redirects/s and 1K new URLs/s with headroom to scale horizontally. Durability - Once a short URL is created, the mapping must never be lost. Uniqueness Guarantee - Two different long URLs must never produce the same short URL. Back-of-the-Envelope Calculation # These numbers allow us to make concrete decisions about storage, caching and partitioning in later sections.