What is a URL Shortener?
A URL shortener is a tool that takes a long, messy web address and turns it into something short and manageable. Think about Google Drive links or Amazon product pages—they get pretty wild!
I recently read that designing a URL shortener is a common first system design test, so let’s break it down and see how we can build one.
Database Schema
If we want to keep track of URLs, we need a database. Think of it like a coat check at a restaurant:
You hand over your coat (long URL)
You get a ticket (short URL)
Later, you return the ticket, and they give you back your exact coat (redirecting to the original URL)
A simple schema might look like this:
| Column | Type | Description |
|---|---|---|
| id | UUID / Int | Unique identifier for each URL |
| longURL | String | The original long URL |
| shortURL | String | The shortened version |
| clicks | Integer | (Optional) Track number of uses |
| createdAt | Timestamp | (Optional) When the URL was created |
Basic Endpoints (POST to Create, GET to Redirect)
Our app needs two core endpoints:
POST /shorten – Takes a long URL and returns a shortened version
GET /:shortURL – Redirects users from the short URL to the original long URL
When a user enters a long URL, we POST it to create a short version. Later, when someone clicks the short link, we GET the original and redirect them.
Simple but effective!
URL Generation Strategy
How do we generate the short URL? There are a few options:
1️⃣ Hashing the URL
Take the long URL, run it through a hash function, and use part of the hash as the short URL.
Pros: Consistent and deterministic.
Cons: Hash collisions (two URLs creating the same short code), no custom URLs, and inconsistent length.
2️⃣ Random Strings (NanoID)
Generate a random unique string like "xs#$19F".
Pros: Low collision risk, used by companies like Vercel for deployment URLs.
Cons: Doesn’t derive from the original URL.
A better approach? NanoID—a lightweight package that generates collision-resistant unique IDs. Large companies like Vercel use this for their deployment URLs.
How It Works in Our App
- User enters a long URL
- We generate a NanoID-based short URL
- We store both in our database
- We return something like mysite.com/xs#$19F
** Authentication Needs**
So far, anyone can create or use our short URLs. But what if we want user accounts so they can manage their links?
We’d need:
✅ User authentication (login, signup)
✅ Tokens to remember logged-in users
Where Do We Store Tokens?
LocalStorage? ✅ Good for personal apps but not secure
Access token in memory + refresh token in HTTP-only cookie? ✅ More secure and scalable
If a user logs in and we need multiple pages to know who they are, we have to share state across the app.
Small app? → Use React's useContext (like a family group chat—everyone gets the message at once).
Larger app? → Use Redux for global state management.
Scaling Up: Handling High Traffic
What if our awesome URL shortener goes viral?
We don’t want it crashing under heavy traffic, so we use a load balancer to:
🔹 Distribute requests evenly across multiple servers
🔹 Prevent server overload
Thankfully, cloud providers handle most of this for us.
Error Handling & Security
Things will go wrong. It’s our job to handle them well.
Common Errors to Plan For
❌ Invalid URL? → “That’s not a valid address.”
❌ Short URL doesn’t exist? → “We couldn’t find that link.”
❌ Too many requests? → “Slow down, cowboy/cowgirl!” (Rate limiting)
Security Considerations
Is the user logged in? If not, they can’t see their URL history.
Is this the owner? Only the creator should modify or delete a short URL.
Is this a safe URL? Prevent malicious redirects (phishing links).
Future Features
💡 Custom Short URLs – Let users create something like mysite.com/my-brand
💡 Expiration Dates – Set URLs to expire after a certain time
💡 API Access – Allow developers to generate short URLs programmatically
💡 Advanced Analytics – Track referrers, device types, locations
Final Thoughts
Building a URL shortener might seem simple, but it’s a great system design test because it touches databases, backend logic, authentication, performance, and security.
Top comments (0)