Design a URL shortener like bit.ly or tinyurl.

The complete answer guide: what this question really tests, two example strong answers in different angles, the common weak answer rewritten, and the trap most candidates fall into. This is a system design archetype question — see the broader pattern guide for the structural shape.

What this question is really testing

The interviewer isn't evaluating whether you can design a URL shortener—the basic system is straightforward enough that most senior engineers could sketch it in their sleep. What they're actually measuring is whether you can navigate ambiguity systematically and make engineering tradeoffs explicit. They're watching to see if you ask clarifying questions before diving into solutions, if you can estimate scale realistically, and whether you understand that different usage patterns (read-heavy vs write-heavy, global vs regional, public vs private) fundamentally change the architecture. The binary read they're making: do you think like a product engineer who designs systems to solve real problems, or like someone who memorized a template from a YouTube video?

The deeper signal is about prioritization under constraints. A weak candidate will try to design the perfect system that handles every edge case. A strong candidate will explicitly state assumptions, design for the 80% case first, then systematically layer in complexity only when asked. The interviewer wants to see you make decisions like "I'm choosing a hash-based approach over auto-increment IDs because collision handling is easier to reason about than distributed counter coordination, and the tradeoff is worth it given our scale." They're worried you'll either get lost in implementation details (how exactly does base62 encoding work?) or stay so high-level that you never demonstrate technical depth. The question is a tightrope walk between architecture and implementation.

Two strong answers, two angles

Angle A: Scale-first systematic approach

"Let me start by clarifying the requirements—are we designing for bit.ly scale, which is handling billions of URLs with global distribution, or something smaller? Assuming bit.ly scale, we're looking at maybe 1000 writes per second and 10,000 reads per second given the read-heavy nature. I'd design this with a hash-based approach using MD5 of the URL plus a counter for collisions, taking the first 7 characters after base62 encoding to give us 3.5 trillion possible URLs. For storage, I'd use a distributed key-value store like DynamoDB with the short code as the key, which gives us single-digit millisecond reads globally. The write path would include a collision check, and I'd add a Redis cache layer in front for the 80% of URLs that follow a power-law distribution of access. For analytics, I'd stream click events to Kinesis rather than blocking the redirect, since availability matters more than perfect accuracy for view counts."

Angle B: Constraint-driven iterative design

"I'll design this iteratively, starting simple and adding complexity where needed. Version one is a single Postgres database with two columns: original URL and a short code generated from an auto-incrementing ID converted to base62—this handles thousands of requests per second easily and we can build it in a day. The critical bottleneck will be the database becoming a single point of failure, so version two adds read replicas and puts Redis in front for caching popular URLs. When we hit write scaling limits, we switch from auto-increment to a distributed ID generation service like Twitter's Snowflake, which gives us time-ordered IDs across multiple database shards. I'd shard by hash of the short code, not user ID, because most URLs are accessed anonymously and we want even distribution. Custom domains and analytics are features I'd add after validating the core redirect path can handle our SLA of 99.9% availability with p99 latency under 100ms."

The common weak answer

"I'd use a hash function to convert the long URL to a short code, store it in a database, and when someone visits the short URL, I'd look it up in the database and redirect them. I'd probably use MongoDB for the database and add some caching with Redis to make it faster. For high availability, I'd use multiple servers with a load balancer."

This answer fails because it demonstrates solution pattern-matching without demonstrating judgment. You've listed technologies without justifying why they fit this specific problem—why MongoDB over Postgres? Why is document storage relevant here? The interviewer reads this as "memorized a generic architecture diagram" rather than "can reason about tradeoffs." You haven't shown any awareness of scale (is this 10 requests per second or 10,000?), haven't addressed the core algorithmic decision (hash-based vs counter-based short code generation), and haven't acknowledged that URL shorteners have a specific access pattern (extremely read-heavy, power-law distribution) that should drive the design. Reframe: "Given that URL shorteners are typically 100:1 read-to-write ratio with power-law access patterns, I'd optimize for read latency first with aggressive caching, then work backward to determine what write-path complexity we can afford."

The one trap most candidates fall into

The trap is diving into the encoding algorithm before establishing the system boundaries. Candidates spend ten minutes explaining how base62 encoding works, drawing out the character set, and walking through collision handling for hash functions—all implementation details that matter far less than the architectural decisions. This happens because the encoding problem feels concrete and solvable, while questions like "how do we handle distributed writes" or "what's our consistency model" feel ambiguous. The interviewer watches you burn time on the least important part of the system and concludes you can't distinguish between what matters and what doesn't.

The counterintuitive reality is that the URL shortening algorithm is the least interesting part of this system. Whether you use the first 7 characters of an MD5 hash or a base62-encoded counter is a 30-second decision with clear tradeoffs (hashes avoid coordination but need collision handling; counters need distributed coordination but guarantee uniqueness). What actually matters is whether you recognize this is a caching problem, whether you understand the redirect path is your critical path and must be optimized ruthlessly, and whether you can articulate why eventual consistency is acceptable for analytics but not for the core URL mapping. Start with "The key insight is that this is a read-heavy key-value lookup problem with a global access pattern" and you've immediately signaled that you see the forest, not just the trees.

Common questions

Other system design questions