Skip to main content
Abstract Algorithms Logo
Abstract Algorithms
← All Problems·system designMedium~35 min

Design a URL Shortener

Design a URL shortening service similar to bit.ly or TinyURL. Users submit a long URL and receive a short alias (e.g., https://short.ly/aB3xY). When a user visits the short URL, the service redirects them to the original. The service must handle high read traffic, provide low-latency redirects, and allow optional analytics per short URL.

Requirements

  • ✓Given a long URL, generate a unique short alias and return it to the user.
  • ✓Given a short alias, resolve and redirect to the original URL with low latency.
  • ✓Short aliases must be unique and collision-resistant.
  • ✓Optionally support custom aliases chosen by the user.
  • ✓Optionally record click count and basic analytics per short URL.
  • ✓Short URLs should not expire by default; expiry is an optional configuration.

Constraints & Scale

  • —Write volume: ~100 million new URLs per day (assume 100:1 read-to-write ratio).
  • —Redirect p99 latency target: under 10 ms.
  • —Alias length: 7 characters (default) using [a-z, A-Z, 0-9] — 62^7 ≈ 3.5 trillion combinations.
  • —Data retention: indefinite unless expiry is explicitly set.
  • —Assume globally distributed read traffic, writes concentrated in a few regions.
📐

Interactive Architecture Blueprint1 view

Visual topology, node responsibilities, traffic flow steps, and bottlenecks.

Understand
Guided mode

Before designing, clarify the problem scope. What are the core functional requirements? What constraints and scale assumptions define the design space? Identify what is given, what you must assume, and what is explicitly out of scope.

Context & Constraints — Human Reviewed

Core requirements: generate short alias → store mapping → resolve + redirect. Key constraints: 100M writes/day ≈ 1,160 writes/sec; 100:1 read ratio ≈ 116,000 reads/sec; 62^7 alias space; p99 redirect < 10 ms. Out of scope for base design: per-user authentication, abuse prevention, real-time analytics dashboards.

Trade-offs

  • ⚖Global read traffic favors edge caching or a distributed KV store over a single relational DB.
  • ⚖Custom aliases introduce collision risk and require reservation logic separate from the ID generation path.