system design · standard
Design a URL shortener: PM interview answer
Design a URL shortener.
This question is not a test of whether you know base62 encoding. It is a test of whether you know what business you are in. A URL shortener is commodity infrastructure; the real product is the analytics layer on top of it. The candidate who leads with that framing clears the bar. The candidate who opens with a database schema does not.
Structure a strong answer
strong
"Before I get into architecture, let me clarify who we are building this for. A consumer sharing tool, an enterprise marketing analytics platform, and internal infrastructure like t.co have radically different requirements."
There are three distinct user types, and they want different things. Individual sharers want a link that works, nothing more. Enterprise marketers want campaign tracking, UTM integration, a branded short domain, team access, and a dashboard. Developers want a bulk API with rate limits and webhook callbacks on click events.
"Given those users, the core viability question is: URL shortening is commoditized. The business is analytics. I am going to orient every subsequent decision around that."
On the one technical decision that matters most for a PM to name explicitly: 302 vs 301 redirects. A 301 redirect is cached by the browser permanently. Once cached, the server never sees the request again, so analytics become impossible and the destination URL cannot be updated. A 302 redirect preserves server control on every hit. For Bitly, this is not an engineering preference, it is a product strategy decision: their paid product is click data, audience insights, and campaign attribution. The redirect is free infrastructure. "We use 302. We handle the resulting server load with aggressive Redis caching of the hot URL set. The 20% of URLs driving 80% of traffic fit in roughly 25MB per million daily writes."
For MVP scope: short URL creation, 302 redirect with async click logging (queued so the redirect latency is never affected), and a basic click count. Deferred: custom aliases, expiration, branded domains, full analytics dashboard.
On honest tradeoffs: custom aliases feel like a simple polish feature but require collision detection and set a permanence expectation that is very hard to walk back. URL expiration is operationally expensive (cleanup jobs, user communication, broken link risk) and only worth building for specific use cases like event QR codes. Branded short domains (go.shopify.com, amzn.to) are table-stakes for enterprise customers in 2026 and require per-tenant DNS provisioning, which is real infrastructure complexity.
"Two 2026-specific issues I would raise. First, AI-generated content means the phishing surface via short links has grown significantly. Any URL shortener now has a meaningful trust-and-safety problem: LLMs can generate millions of plausible destination pages. We need pre-click safety checks via Google Safe Browsing API as a lightweight first pass, and a link preview option. Second, GDPR and US state privacy laws mean passive click tracking without user notice is legally exposed in most jurisdictions. Our analytics pipeline needs consent flags."
"My north star metric: redirect success rate at p99 latency, not just uptime. A slow redirect destroys the brand value of a short domain. I would set a 50ms redirect SLA and design backward from that."
weak
Jumping straight to base62 encoding and a database schema without asking who the product serves. Listing features (custom aliases, QR codes, expiration) as obviously desirable without naming the operational cost or the user segment that needs them. Treating the redirect as the end state and never mentioning analytics. Performing capacity math with no connection to architecture decisions: estimating 40 writes/second and 4,000 reads/second means nothing unless you connect it to "therefore we start with a single write replica." And not raising abuse or safety at all.
The PM judgment
The interviewer is checking three things: whether you know what business the product is actually in, whether you can name tradeoffs with specificity rather than listing features, and whether you have thought about the 2026 context. A 7-character base62 string gives roughly 3.5 billion unique URLs (62^7), which is more than enough at realistic scale with a counter-based approach. That fact is worth one sentence. The 301 vs 302 decision connected to the business model is worth a paragraph. That proportion tells the interviewer everything about your PM instincts.
The viability framing applies directly here: URL shortening has no durable margin, so the only viable business is the data product sitting on top of the redirect. If you are designing the system, design for the data product first. The redirect is the cost center; the dashboard is the revenue center.
For related technical judgment questions, see what is a database vs cache and design a notification system.