System Design Interview: How to Design a URL Shortener Like Bit.ly

URL shortener design is one of the most common system design interview questions at Google, Meta, and Amazon. This guide walks through capacity estimation, database design, encoding algorithms, and scaling strategies.

Understanding the Problem Space

URL shorteners convert long URLs into short ones — https://example.com/very/long/path becomes https://bit.ly/abc123. At small scale this is trivial. At bit.ly scale (10 billion links, 6 billion clicks per month) it becomes a fascinating distributed systems challenge.

Before designing anything, ask clarifying questions: What is the expected read-to-write ratio? (Typically 100:1 — reads far outweigh writes.) How many new URLs per day? Do URLs expire? Are custom aliases needed? Do we need click analytics? These questions define requirements and prevent over-engineering.

Capacity Estimation

For a large-scale system: assume 100 million new URLs per day, giving 1,160 writes per second. With a 100:1 read ratio, expect 116,000 reads per second. Storage: if each URL record averages 500 bytes and we store five years of data, that is 100M per day times 365 days times 5 years times 500 bytes, roughly 90 terabytes.

A 7-character short code using alphanumeric characters (a-z, A-Z, 0-9) gives 62 to the power of 7, which is 3.5 trillion unique codes. At 100 million new URLs per day, this lasts nearly 100 years. Base62 encoding is the standard approach for generating short codes.

Database Design and Encoding Strategy

The data model is simple: a urls table with columns for id, short_code, original_url, user_id, created_at, expires_at, and click_count. For the access pattern — single key lookup by short_code — a NoSQL key-value store like DynamoDB or Cassandra outperforms relational databases at scale. But PostgreSQL works fine up to hundreds of millions of records with proper indexing.

Two encoding strategies work well. First, auto-increment the ID and Base62-encode it — ID 1 becomes 000001, ID 123456789 becomes 8M0kX. This guarantees uniqueness with no collision checking. Second, take the MD5 or SHA256 hash of the original URL and use the first 7 characters. Faster generation but requires collision detection and retry logic.

Scaling to Handle 116K Reads Per Second

The Pareto principle applies: 20 percent of URLs account for 80 percent of traffic. Cache popular URL mappings in Redis with LRU eviction. A cache hit returns the redirect in under 1ms versus a database query at 5-10ms. With a cache hit rate above 80 percent, you can handle 100K+ reads per second with relatively modest database infrastructure.

For horizontal scaling, add read replicas to the database and put a load balancer in front. Rate limit the write API to prevent abuse. For the redirect itself, return a 301 permanent redirect for SEO-friendly use cases or a 302 temporary redirect when you need accurate click tracking. A CDN at the edge can serve the most popular redirects without hitting your origin servers at all.

Share your thoughts about this article.

Claude AI vs ChatGPT vs Gemini: Which AI Assistant Wins in 2025?

The AI assistant landscape is more competitive than ever. Claude, ChatGPT, and Gemini each excel in ...

What is Vibe Coding? The AI Revolution Turning Everyone into a Developer

Vibe coding is the practice of building software by directing AI with natural language. Coined by An...

Top 10 Programming Languages to Learn in 2025 (Ranked by Demand)

Choosing the right programming language can make or break your career. Here are the top 10 languages...

Never Miss a Tech Article

Join thousands of developers getting the latest AI, coding, and tech tutorials delivered to their inbox every week.

CodeWithBeast is your hub for AI, coding, and the latest in tech. Empowering developers, creators, and learners worldwide.

Get in touch

Our Social Network

System Design Interview: How to Design a URL Shortener Like Bit.ly