URL Shortener System Design: Hoe Link Shorteners Onder de Motorkap Werken

"Ontwerp een URL shortener" is een van de meest populaire system design interview vragen — en terecht. Het raakt hashing, databases, caching, load balancing, en distributed systems, allemaal in een bedrieglijk simpel product.

In deze gids lopen we door hoe URL shorteners daadwerkelijk werken, de belangrijkste ontwerpbeslissingen, en de afwegingen op grote schaal.

Een URL shortener doet twee dingen:

1. 1Verkorten: Neem een lange URL en genereer een korte code
2. 2Omleiden: Wanneer iemand de korte URL bezoekt, stuur ze door naar het origineel

Hier is de high-level flow:

Gebruiker maakt korte link:
  Lange URL → Genereer korte code → Sla mapping op → Retourneer korte URL

Gebruiker klikt op korte link:
  Korte URL → Zoek code op → Vind lange URL → 301 Redirect

De kernuitdaging is het genereren van unieke, korte codes. Er zijn verschillende benaderingen:

Converteer een auto-incrementerende ID naar een Base62 string met karakters [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238.328 → ZZZ

Een 7-character Base62 code ondersteunt 62^7 = 3,5 biljoen unieke URLs.

Voordelen: Eenvoudig, voorspelbare lengte, geen botsingen Nadelen: Opeenvolgende IDs zijn voorspelbaar (gebruikers kunnen andere korte URLs raden)

Pas een hash functie (MD5, SHA-256) toe op de lange URL en neem de eerste N karakters:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Korte code: "a3f2b8c"

Voordelen: Dezelfde invoer produceert altijd dezelfde uitvoer (deduplicatie) Nadelen: Hash botsingen vereisen afhandeling; vaste hash lengte kan ruimte verspillen

Genereer een willekeurige alfanumerieke string en controleer op uniciteit:

Voordelen: Eenvoudig, onvoorspelbaar Nadelen: Vereist botsingcontrole bij elke creatie; wordt langzamer naarmate de database volloopt

De meeste productiesystemen gebruiken Base62 codering met een gedistribueerde ID generator. Het is eenvoudig, botsingvrij, en performant. Bij Linkly gebruiken we een vergelijkbare benadering — u kunt meer lezen over hoe URL shorteners werken voor een minder technisch overzicht.

De kerntabel is eenvoudig:

urls ├── id (primary key, auto-increment) ├── short_code (unique index) ├── long_url (de bestemming) ├── created_at (timestamp) ├── user_id (wie het heeft gemaakt) └── click_count (gedenormaliseerde teller)

SQL (PostgreSQL, MySQL): ACID compliance, sterke consistentie, goed voor gematigde schaal. De meeste URL shorteners beginnen hier.

NoSQL (DynamoDB, Cassandra): Betere horizontale schaling voor miljarden URLs. Uiteindelijke consistentie is aanvaardbaar voor dit geval.

Hybride: SQL voor URL mappings (sterke consistentie nodig voor redirects), NoSQL of een time-series database voor click analytics (hoog schrijfvolume, uiteindelijke consistentie is prima).

Wanneer een gebruiker op een korte link klikt, moet het systeem:

1. 1De korte code uit de URL parseren
2. 2De bijbehorende lange URL opzoeken
3. 3Een HTTP redirect response retourneren

• 301 (Permanent): Browser cacht de redirect. Minder serveraanvragen, maar je verliest zicht op herhaalde klikken.
• 302 (Tijdelijk): Browser controleert met de server elke keer. Meer aanvragen, maar beter click tracking.

De meeste URL shorteners gebruiken 302 redirects voor click tracking nauwkeurigheid, en bieden dan 301 als optie voor SEO use cases. Zie onze gids op 301 redirects voor meer over dit onderscheid.

Redirects moeten snel zijn — elke milliseconde latentie beïnvloedt de gebruikerservaring. Caching is kritiek:

Cache de mapping short_code → long_url in geheugen:

GET /abc123 → Controleer Redis voor "abc123" → Cache hit? Retourneer redirect onmiddellijk → Cache miss? Query database, cache resultaat, retourneer redirect

Een kleine Redis instance kan miljoenen URL mappings cachen. Omdat het meeste verkeer naar een relatief klein aantal populaire links gaat, zijn cache hit rates boven de 90% gebruikelijk.

Voor 301 redirects kunnen CDN edge nodes de redirect response cachen, servering vanuit de locatie het dichtst bij de gebruiker zonder uw origin server helemaal te raken.

Het registreren van clickdata is een schrijf-intensieve operatie die de redirect niet moet vertragen:

1. 1Gebruiker klikt op korte link
2. 2Systeem retourneert onmiddellijk de redirect
3. 3Click event wordt naar een message queue geduwd (Kafka, RabbitMQ, SQS)
4. 4Een background worker verwerkt het event: parsed user agent, geolocates IP, slaat analytics op

Dit ontkoppelt het snelle redirect pad van de langzamere analytics pipeline.

• Timestamp
• IP address (voor geolocatie)
• User agent (voor device/browser detectie)
• Referrer header
• Land, stad (van IP geolocatie)

URL shorteners zijn extreem lees-zwaar. Een typische ratio zou 100:1 reads naar writes kunnen zijn. Dit betekent:

• Optimaliseer het redirect pad bovenal
• Gebruik caching agressief
• Lees replicas voor de database

Als je auto-incrementerende IDs gebruikt over meerdere servers, moet je botsingen voorkomen. Opties:

• Snowflake IDs: Twitter's benadering — embed timestamp, machine ID, en sequence number
• UUID: Universeel uniek maar langer
• ID ranges: Ken elke server een bereik van IDs toe om toe te wijzen

Implementeer redirect servers in meerdere regio's. Een gebruiker in Tokyo hoeft niet naar een server in Virginia voor een redirect.

URL shorteners kunnen worden misbruikt voor phishing en malware distributie. Productiesystemen hebben nodig:

• URL scanning — controleer bestemmingen tegen malware en phishing databases
• Rate limiting — voorkom massale creatie van kwaadaardige korte links
• Misbruik rapportage — sta gebruikers toe verdachte links te rapporteren
• Preview pagina's — toon gebruikers optioneel waar een link heen gaat voor het omleiden

Meer informatie over link veiligheid en click fraud bescherming.

Beyond basale verkorting en omleiding, productie URL shorteners voegen toe:

• Aangepaste domeinen — merkgebonden korte links met uw eigen domein
• Aangepaste slugs — kies uw eigen korte code in plaats van willekeurige karakters
• Vervaldatum — tijdsbeperkte links die stoppen met werken na een datum
• Wachtwoordbeveiliging — vereisen een wachtwoord om de bestemming te openen
• A/B testing — roulatie tussen meerdere bestemmingen
• Geo-targeting — omleiden per land
• Device targeting — verschillende bestemmingen voor mobiel vs. desktop
• QR codes — genereer scanbare codes voor elke korte link

URL shortener system design is een geweldige oefening omdat het eenvoudig begint maar lagen complexiteit onthult: code generatie, database ontwerp, caching, analytics pipelines, en misbruik preventie. Het begrijpen van deze fundamentals helpt of je nu voor interviews voorbereidt of je eigen tools bouwt.

Wilt u een productie URL shortener gebruiken zonder er een zelf te bouwen? Start met Linkly — alle architectuur beschreven hierboven, klaar om te gebruiken met aangepaste domeinen, analytics, en geavanceerde functies.