I've coached dozens of Flutter developers through system design interviews. The URL shortener question comes up constantly — it's the "FizzBuzz" of system design. And almost everyone makes the same mistakes.

Here are the 5 I see most often, and how to fix them.

---

1. Jumping Straight Into the Database Schema

The interviewer says "design a URL shortener" and you immediately start talking about PostgreSQL columns. Stop.

The first 5 minutes should be clarifying requirements. Ask about scale (1,000 URLs/day vs 100 million), read/write ratio, analytics needs, custom short codes, and expiration. These answers completely change your architecture.

An interviewer would rather hear great questions than a premature schema.

2. Using MD5/SHA256 and Hoping for the Best

"I'll hash the URL with MD5 and take the first 7 characters."

This has a collision probability problem. With 7 Base62 characters, you have ~3.5 trillion possible codes. But the birthday paradox means you'll hit a 50% collision chance at only ~2.6 million URLs if you're truncating a hash. That's not production-grade.

Better approach: Use a pre-generated key pool or a Base62-encoded atomic counter. Zero collisions by design.

3. Ignoring the Read/Write Ratio

URL shorteners are massively read-heavy. A typical ratio is 100:1 — for every URL created, it gets clicked 100 times. If you design your system optimized for writes, you've missed the point.

This means:

• Read replicas are essential, not optional

• Redis caching should be your first line of defense for redirects

• Your database choice should prioritize read throughput

4. Using 301 Redirects Without Thinking

301 (Permanent Redirect) tells browsers to cache the redirect forever. The browser will never hit your server again for that short code.

Great for reducing load. Terrible for analytics. If you need click tracking (you almost always do), use 302 (Temporary Redirect) so every click hits your server and gets logged.

This is a one-sentence answer that shows you understand HTTP semantics. Interviewers love it.

5. Forgetting About Cleanup

What happens to expired URLs? What about URLs that haven't been clicked in 3 years?

Most candidates design a system that only grows. Production systems need:

• A background job that purges expired URLs

• A strategy for recycling short codes from deleted URLs

• Storage cost projections that account for data retention policies

---

The Bottom Line

The URL shortener question isn't about building a URL shortener. It's about demonstrating that you can think through trade-offs, estimate scale, and design for production realities.

Nail these 5 points and you're already ahead of 80% of candidates.

If you want to go deeper — full architecture, Flutter implementation, caching strategies, and a complete mock interview walkthrough — that's exactly what I built the course for.