The latest articles on DEV Community by DesignBeyondCode (@designbeyondcode). https://dev.to/designbeyondcode https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4229721%2F5fdc207c-afb8-44c5-95d0-08460b8d5a87.png https://dev.to/designbeyondcode en DesignBeyondCode Mon, 09 Nov 2026 18:01:04 +0000 https://dev.to/designbeyondcode/design-a-url-shortener-start-with-one-server-and-let-the-numbers-grow-it-46ec https://dev.to/designbeyondcode/design-a-url-shortener-start-with-one-server-and-let-the-numbers-grow-it-46ec <p>Most answers to "design a URL shortener" start with the final picture: load balancers, a cache cluster, Kafka, ten boxes. Interviewers see that every day. It shows you remember a diagram, not that you can design.</p> <p>A better answer starts small. Then you let the numbers decide each next step. Here's the short version.</p> <h2> First, the numbers </h2> <p>Say people create 100 million links a month, and each link gets about 100 clicks.</p> <ul> <li>That's about 40 new links a second. One normal database can handle it.</li> <li>It's about 4,000 clicks a second, and maybe 10 times that when one link goes viral. That's a lot of reads, so we'll need a cache.</li> <li>Over 10 years we need about 12 billion short codes. Seven characters (letters and digits) give us 3.5 trillion, so 7 is plenty.</li> </ul> <p>So the data is small, and the reads are many. Everything below follows from that.</p> <h2> Step 1: one server, one table </h2> <p>A table that maps each short code to its long URL. One endpoint to create a link, one to redirect. Start here in the interview. It's fine to say it won't last.</p> <h2> Step 2: make codes without waiting </h2> <p>If every new link asks the database for the next number, every server waits on that one database. Instead, each server takes a block of 10,000 numbers at once and hands them out from memory. Two servers never get the same block, so codes never clash.</p> <p>We also shuffle the numbers with a secret key. Otherwise codes made one after another look alike, and anyone could walk through every link.</p> <h2> Step 3: a cache for clicks </h2> <p>Here's the nice part. A link's target never changes. So a cached copy can be missing, but it can never be wrong. Each click checks a small cache in the server's memory, then Redis, and only then the database.</p> <h2> Step 4: count clicks later </h2> <p>The redirect shouldn't wait for analytics. It drops a small "someone clicked" event into a queue and answers right away. Another job adds up the clicks in the background.</p> <h2> The question that changes the answer </h2> <p>Should the redirect be a 301 or a 302? A 301 tells browsers to remember it forever. You get less traffic, but you stop seeing clicks, and you can't stop a bad link after you delete it. A 302 keeps every click coming back to you. So ask the interviewer about analytics early. It decides this.</p> <h2> When one link goes viral </h2> <p>The traffic itself is fine. The danger is the moment that link drops out of the cache. Thousands of requests miss at once and all hit the database. The fix: keep hot links in each server's memory for a few seconds, and let only one request reload a link while the others wait.</p> <p>I wrote the full version on my site. It has a diagram you can grow step by step, a calculator for the numbers, "what breaks" scenarios, and code in five languages. It's free, no sign-up: <a href="https://designbeyondcode.com/system-design/problems/url-shortener/" rel="noopener noreferrer">Design a URL shortener</a></p> architecture interview systemdesign