Conception d'un système de raccourcisseur d'URL : comment fonctionnent les raccourcisseurs de liens sous le capot

« Concevoir un raccourcisseur d'URL » est l'une des questions d'entretien de conception de système les plus populaires — et à juste titre. Elle touche au hachage, aux bases de données, à la mise en cache, à l'équilibrage de charge et aux systèmes distribués, le tout dans un produit apparemment simple.

Dans ce guide, nous verrons comment fonctionnent réellement les raccourcisseurs d'URL, les décisions de conception clés et les compromis impliqués à grande échelle.

Un raccourcisseur d'URL fait deux choses :

1. 1Raccourcir : Prendre une URL longue et générer un code court
2. 2Rediriger : Quand quelqu'un visite l'URL courte, le rediriger vers l'original

Voici le flux de haut niveau :

L'utilisateur crée un lien court :
  URL longue → Générer un code court → Stocker le mappage → Retourner l'URL courte

L'utilisateur clique sur le lien court :
  URL courte → Rechercher le code → Trouver l'URL longue → Redirection 301

Le défi central est de générer des codes uniques et courts. Il existe plusieurs approches :

Convertir un ID auto-incrémenté en chaîne Base62 en utilisant les caractères [a-zA-Z0-9] :

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

Un code Base62 de 7 caractères supporte 62^7 = 3,5 trillions d'URL uniques.

Avantages : Simple, longueur prévisible, pas de collisions Inconvénients : Les ID séquentiels sont prévisibles (les utilisateurs peuvent deviner d'autres URL courtes)

Appliquer une fonction de hachage (MD5, SHA-256) à l'URL longue et prendre les N premiers caractères :

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

Avantages : La même entrée produit toujours la même sortie (déduplication) Inconvénients : Les collisions de hachage nécessitent une gestion ; la longueur de hachage fixe peut gaspiller de l'espace

Générer une chaîne alphanumérique aléatoire et vérifier l'unicité :

Avantages : Simple, imprévisible Inconvénients : Nécessite une vérification de collision à chaque création ; devient plus lent au fur et à mesure que la base de données se remplit

La plupart des systèmes de production utilisent l'encodage Base62 avec un générateur d'ID distribué. C'est simple, sans collision et performant. Chez Linkly, nous utilisons une approche similaire — vous pouvez en savoir plus sur comment fonctionnent les raccourcisseurs d'URL pour un aperçu moins technique.

La table centrale est simple :

urls ├── id (clé primaire, auto-incrémenté) ├── short_code (index unique) ├── long_url (la destination) ├── created_at (timestamp) ├── user_id (qui l'a créé) └── click_count (compteur dénormalisé)

SQL (PostgreSQL, MySQL) : Conformité ACID, cohérence forte, bon pour l'échelle modérée. La plupart des raccourcisseurs d'URL commencent ici.

NoSQL (DynamoDB, Cassandra) : Meilleure mise à l'échelle horizontale pour des milliards d'URL. La cohérence éventuelle est acceptable pour ce cas d'utilisation.

Hybride : SQL pour les mappages d'URL (besoin de cohérence forte pour les redirections), NoSQL ou une base de données de séries chronologiques pour les analyses de clics (volume d'écriture élevé, la cohérence éventuelle convient).

Quand un utilisateur clique sur un lien court, le système doit :

1. 1Analyser le code court de l'URL
2. 2Rechercher l'URL longue correspondante
3. 3Retourner une réponse de redirection HTTP

• 301 (Permanent) : Le navigateur met en cache la redirection. Moins de requêtes serveur, mais vous perdez la visibilité sur les clics répétés.
• 302 (Temporaire) : Le navigateur vérifie avec le serveur à chaque fois. Plus de requêtes, mais meilleur suivi des clics.

La plupart des raccourcisseurs d'URL utilisent des redirections 302 pour la précision du suivi des clics, puis offrent 301 en option pour les cas d'utilisation SEO. Consultez notre guide sur les redirections 301 pour en savoir plus sur cette distinction.

Les redirections doivent être rapides — chaque milliseconde de latence affecte l'expérience utilisateur. La mise en cache est critique :

Mettez en cache le mappage code_court → URL_longue en mémoire :

GET /abc123 → Vérifier Redis pour "abc123" → Succès du cache ? Retourner la redirection immédiatement → Échec du cache ? Interroger la base de données, mettre en cache le résultat, retourner la redirection

Une petite instance Redis peut mettre en cache des millions de mappages d'URL. Comme la plupart du trafic va à un nombre relativement petit de liens populaires, les taux de succès du cache supérieurs à 90 % sont courants.

Pour les redirections 301, les nœuds de périphérie du CDN peuvent mettre en cache la réponse de redirection, la servant à partir de l'emplacement le plus proche de l'utilisateur sans frapper du tout votre serveur d'origine.

L'enregistrement des données de clic est une opération d'écriture intensive qui ne doit pas ralentir la redirection :

1. 1L'utilisateur clique sur le lien court
2. 2Le système retourne immédiatement la redirection
3. 3L'événement de clic est envoyé à une file d'attente de messages (Kafka, RabbitMQ, SQS)
4. 4Un processus de travail traite l'événement : analyse l'agent utilisateur, géolocalise l'IP, stocke les analyses

Cela découple le chemin de redirection rapide du pipeline d'analyse plus lent.

• Timestamp
• Adresse IP (pour la géolocalisation)
• Agent utilisateur (pour la détection du navigateur/appareil)
• En-tête de référent
• Pays, ville (à partir de la géolocalisation IP)

Les raccourcisseurs d'URL ont une charge extrêmement dominée par les lectures. Un ratio typique pourrait être 100:1 lectures par rapport aux écritures. Cela signifie :

• Optimiser le chemin de redirection avant tout
• Utiliser la mise en cache de manière agressive
• Réplicas de lecture pour la base de données

Si vous utilisez des ID auto-incrémentés sur plusieurs serveurs, vous devez éviter les collisions. Options :

• ID Snowflake : L'approche de Twitter — incorporer l'horodatage, l'ID de machine et le numéro de séquence
• UUID : Universellement unique mais plus long
• Plages d'ID : Attribuer à chaque serveur une plage d'ID à allouer

Déployez des serveurs de redirection dans plusieurs régions. Un utilisateur à Tokyo ne devrait pas avoir besoin d'un aller-retour à un serveur en Virginie pour une redirection.

Les raccourcisseurs d'URL peuvent être abusés pour l'hameçonnage et la distribution de logiciels malveillants. Les systèmes de production ont besoin de :

• Analyse d'URL — vérifier les destinations par rapport aux bases de données de logiciels malveillants et d'hameçonnage
• Limitation de débit — prévenir la création en masse de liens courts malveillants
• Signalement d'abus — permettre aux utilisateurs de signaler les liens suspects
• Pages d'aperçu — montrer éventuellement aux utilisateurs où va un lien avant de rediriger

En savoir plus sur la sécurité des liens et la protection contre la fraude au clic.

Au-delà du raccourcissement et de la redirection basiques, les raccourcisseurs d'URL de production ajoutent :

• Domaines personnalisés — liens courts de marque utilisant votre propre domaine
• Slugs personnalisés — choisissez votre propre code court au lieu de caractères aléatoires
• Expiration — liens limités dans le temps qui cessent de fonctionner après une date
• Protection par mot de passe — exiger un mot de passe pour accéder à la destination
• Test A/B — faire pivoter entre plusieurs destinations
• Ciblage géographique — redirection par pays
• Ciblage d'appareil — destinations différentes pour mobile vs. bureau
• Codes QR — générer des codes scannables pour n'importe quel lien court

La conception du système de raccourcisseur d'URL est un excellent exercice car elle commence simplement mais révèle des couches de complexité : génération de code, conception de base de données, mise en cache, pipelines d'analyse et prévention des abus. Comprendre ces fondamentaux aide que vous prépariez des entretiens ou que vous construisiez vos propres outils.

Vous voulez utiliser un raccourcisseur d'URL de production sans en construire un ? Commencez avec Linkly — toute l'architecture décrite ci-dessus, prête à être utilisée avec des domaines personnalisés, des analyses et des fonctionnalités avancées.