URL shortening: system design exercise versus the real world.

I came across this blog post from Rebrandly, titled "Why building a link shortener at scale is harder than it looks." Since Rebrandly sells URL shortening services, you can guess the thesis: you can build one yourself, but it's hard, so don't bother and just pay us instead. That argument naturally invites skepticism, but they do make some good points.

I'm interested for a couple of reasons. Designing a URL shortener is a classic system design problem, so I was glad to see it discussed as a real production system rather than a whiteboard exercise. It also touches on some timely themes: the build-versus-buy decision, the role of vendors, and whether AI is actually changing the nature of software development.

I like the subject matter and I agree with most of the arguments. That said, the piece has problems. Ironically, given the topic, it shows signs of AI writing. More importantly, while I agree with the broad strokes, I kept wanting more detail that would have made the arguments land harder.

I love their observation that link records and click data need different storage. Your links table is small, append-mostly, and read on the hot path; your click stream is high-volume, write-heavy, and queried analytically. Stuffing both into one Postgres instance and hoping for the best is a real mistake teams make, and decoupling them early is good advice. This is the kind of engineering insight that makes company engineering blogs worth reading, and I wanted more of it.

Instead, I'm left wanting a deeper discussion of what it actually takes to run a URL shortener at scale and in production. Were there particular pain points? What features and user interactions does Rebrandly support that a typical coding-exercise implementation doesn't? What did their journey to get here look like? I want to understand how a production URL shortener differs from a system design exercise.

That absence matters more because of their own observation that AI "makes the initial build faster and cheaper." That's especially true for a URL shortener: the design is so well documented that implementing one is almost a memorization exercise, so it's no surprise an LLM can do it. But AI giving you a shortener that's adequate for a coding interview is not the same as giving you one that's production-ready, and this is exactly where a few war stories from Rebrandly would have reinforced the point.

The core point of the post is that however easy the initial build is (even with AI, although I'm not completely sold on AI's effectiveness), infrastructure and availability remain the hard part. My own background is in distributed systems, with an emphasis on reliability and scale, and to me, this isn't the dark art the article implies, but it isn't easy or trivial either.

Moreover, I disagree with the tone taken. The piece leans on scare tactics, describing inevitable production incidents with dire consequences, and I don't think it needs to. The truth here is enough: doing this right takes real time, effort, and resources, and the process will be bumpy. But being able to do something yourself doesn't make it worth doing, and that's where a vendor comes in — peace of mind and convenience.