Design a URL Shortening Service (TinyURL)

Design a URL shortening service that creates durable short links and keeps redirects fast and available as traffic and link popularity grow.

URL shortener is a compact system design problem with unusually rich trade-offs. Two independent Google interview reports describe this prompt, including demand estimation and large-scale service design. The strongest answers quantify the code space, make retry and collision behavior explicit, and protect the read-heavy redirect path from secondary work.

Problem and Interview Evidence

Design a service that converts long URLs into short links and redirects each short code to its active destination. A Google Senior Software Engineer report describes estimating demand and designing for that demand, while a separate Google L5 report names URL shortener as its system design round. Treat the company association as evidence-backed, but expect the interviewer to vary scope and scale.

Requirements and APIs

Start with POST /links and GET /{code} semantics. Clarify expiry, custom aliases, disabled links, and whether repeated create requests must be idempotent. Keep click analytics asynchronous. A useful design states which operation requires strong uniqueness, what a redirect returns for expired or blocked links, and how clients retry safely.

Key Generation and Correctness

Compare random codes, encoded counters, and allocated identifier ranges. Quantify the available key space rather than saying it is large. Explain collision detection, atomic ownership, predictability, and how code length evolves. Custom aliases require an authoritative uniqueness check even when ordinary codes are generated without coordination.

Fast Redirects at Scale

Trace the redirect from edge or load balancer through cache to the authoritative mapping store. Cover cache misses, negative caching, TTL choice, viral hot links, and request coalescing. Analytics events should enter a durable asynchronous pipeline without increasing normal redirect latency or making redirects depend on the analytics system.

Failure and Abuse

Define what remains available during cache, zone, and regional failures. Discuss stale mappings, replication lag, disabled-link propagation, malicious destinations, creation rate limits, and monitoring. Strong designs distinguish durable mapping state from disposable cache state and provide a safe degraded mode for the dominant read path.