URL Shortener

Problem Statement

Design a URL shortening service like Bit.ly or TinyURL that converts long URLs into shorter aliases and redirects users to the original URL when the short link is visited.

Functional Requirements

FR1 – Users can shorten a long URL

A user submits a long URL and receives a short URL such as https://sho.rt/aB12xY. The system stores the mapping from short_alias to long_url.

FR2 – Users can visit a short URL and get redirected to the original URL

When a user opens the short URL, the system resolves the alias and returns an HTTP redirect to the original long URL.

FR3 – Users can optionally request a custom alias

A user may request a readable alias such as https://sho.rt/showoffer. The system should only accept it if the alias is available.

FR4 – The system records basic click analytics

The system should record events such as short_alias, timestamp, referrer, and coarse location/device metadata. Analytics should not block the redirect path.

Non-Functional Requirements

NFR1 – High Scalability

The system should support far more reads than writes. A reasonable interview assumption is 100M shortened URLs created per month and 10B redirects per month.

Illustration: Most short links are created once but may be opened many times. Therefore, the redirect path is the hot path.

Scalability is not only about request volume. It is also about how many unique aliases the system can generate over time. If we use Base62 encoding, each character can be one of 62 symbols: 0-9, a-z, and A-Z. An alias of length L can represent 62^L unique aliases.

At 100M new URLs per month, the system creates about 1.2B URLs per year. A 6-character Base62 alias can mathematically last for many years, but 7 characters is a safer production default because it leaves room for reserved ranges, deleted links, custom aliases, uneven distribution, and future growth.

Think About It: Which path actually needs the most scaling?

Many candidates say, "the system should be scalable," but that statement is too broad. A stronger answer asks: scalable for what operation? In a URL shortener, the write path creates mappings, but the read path performs redirects. Redirects usually dominate by a large margin.

Why this matters: if we optimize the wrong path, we may over-engineer URL creation and under-design redirect lookup. URL creation can often tolerate tens or hundreds of milliseconds because the user is waiting for a short link to be generated. Redirects are different: every click is user-facing, and the user expects to land on the target page immediately.

Design answer: treat the system as read-heavy. Use the database as the source of truth, but do not make the database serve every redirect. Add Redis or another low-latency cache in front of the database. For extremely hot links, we can later discuss CDN or edge caching, but the core design should already show that redirect lookup is the main scale problem.

Interview signal: quantify the workload and name the hot path. For example: "If we have 10B redirects per month and 100M URL creations per month, redirects are roughly 100x heavier than writes, so I will optimize the redirect path first."

NFR2 – Low Redirect Latency

The redirect path should be very fast, ideally P95 under 50–100ms for cache hits.

Illustration: If a short link is embedded in ads, emails, SMS, or social posts, every extra delay hurts user experience.

NFR3 – Availability and Consistency Strategy

A strong answer should not label the entire system as simply "AP" or "CP." Different workflows have different consistency needs.

• Creation path: prefer consistency over availability for alias uniqueness and durable mapping writes.
• Redirect path: prefer availability and low latency for already-created mappings.
• Analytics path: prefer availability and eventual consistency because analytics is not on the critical user path.

NFR4 – URL Mapping Durability

Once the system returns a short URL to the user, the mapping must be durably stored. Losing a mapping means the short link is permanently broken.

NFR5 – Eventual Consistency for Analytics

Analytics can be slightly delayed. The user should be redirected immediately, while click events are processed asynchronously.

Think About It: Should analytics be correct immediately, or should redirect be fast?

This is one of the cleanest tradeoffs in the problem. When a user clicks a short URL, there are two possible pieces of work: redirecting the user and recording the click. Only one is required for the user experience. The redirect must happen now. Analytics can happen later.

Why synchronous analytics is risky: if the redirect service writes analytics directly to an analytics database before returning the 302, analytics latency becomes user-facing latency. If analytics storage is slow, overloaded, or temporarily down, redirects become slow or unavailable. That is the wrong dependency direction.

Design answer: emit a ClickEvent to a durable queue and return the redirect immediately. Analytics consumers can process events asynchronously and update raw event storage or aggregate tables. If the analytics pipeline is delayed, dashboards may lag, but short links still work.

Design philosophy: separate critical path from side effects. Redirect is the critical path. Analytics is a side effect. A senior design should protect the critical path from non-critical failures.

Requirement Summary

Before diving into entities and APIs, notice the key shape of this problem: URL creation is write-heavy enough to need unique ID generation, but redirect is the true hot path. This drives almost every design decision: caching, database indexing, read replicas, and asynchronous analytics.