Guide complet gratuit
Concevez service de liens courts.
Le rythme de l’entretien reste compact, pour que la page consacre son attention aux vraies décisions de conception.
Ne vous contentez pas d’énoncer les besoins : demandez-les. Chaque carte associe la contrainte de conception à une question de clarification que vous pouvez dire à voix haute avant de dessiner l’architecture.
01Les utilisateurs devraient-ils pouvoir choisir un alias personnalisé, ou un code court généré par le système suffit-il ?
Les utilisateurs peuvent soumettre une URL longue et récupérer un lien court unique — code base62 généré par le système (lettres + chiffres) par défaut, alias personnalisé en option.
02Les liens durent-ils indéfiniment, ou faut-il une expiration et un nettoyage ?
Les utilisateurs peuvent définir une expiration optionnelle ; un lien expiré cesse de rediriger et son code peut être retiré ultérieurement.
03La redirection elle-même est-elle le flux central — quelque chose d'autre doit-il se produire au clic ?
Quiconque ouvre un lien court est redirigé vers l'URL d'origine — de loin l'opération la plus fréquente. Chaque clic doit aussi être enregistré, et l'enregistrement ne doit jamais retarder la redirection.
04Les campagnes marketing nécessitent-elles une création en masse — des milliers de liens en un seul appel ?
Prendre en charge la création par lots : une campagne génère des milliers de liens en une seule requête.
05Un lien peut-il être reciblé vers une nouvelle destination après sa création ?
Les liens ne changent pas une fois créés. Le reciblage vers une nouvelle destination est une option supplémentaire. Après un reciblage, les visiteurs doivent atterrir sur la nouvelle destination, jamais l'ancienne.
06À qui appartient un lien — les créateurs peuvent-ils lister et désactiver les leurs ?
Les liens appartiennent à leur créateur : lister, désactiver et retirer — un lien désactivé doit cesser de rediriger en quelques secondes.
Hors périmètreTableau de bord analytique — seule l'émission asynchrone d'événements de clic reste dans le périmètre · Comptes utilisateurs, authentification et interface de gestion des liens · Analyse anti-spam et URL malveillantes
01Quel ratio lecture/écriture supposer — est-ce fortement orienté lecture ?
Dominé par la lecture : environ 100M de personnes suivent un lien court un jour typique, contre environ 1M de nouveaux liens créés. Cela fait au moins 100:1 de redirections contre créations. Les déploiements orientés marketing tournent plutôt à 1000:1, donc il vaut la peine de demander lequel c'est ici.
02À quel point une redirection doit-elle sembler rapide à l'utilisateur ?
Redirection p95 sous 100 ms — le saut du lien court doit sembler invisible à la personne qui clique.
03Un lien tout neuf doit-il se résoudre instantanément partout, ou un léger délai est-il acceptable ?
Disponibilité plutôt que cohérence : les redirections visent 99,99 %. Un lien tout juste créé peut mettre quelques secondes à atteindre tous les caches et réplicas (cohérence éventuelle acceptée).
04Pour combien de liens au total l'espace de codes et le stockage doivent-ils être dimensionnés ?
Prévoir ~1 milliard de liens. Un code base62 de 7 caractères donne 62^7 ≈ 3,5 billions de codes possibles, largement de la marge. À ~1 Ko par ligne, le stockage total reste proche de 1 To, shardable par code court.
05Deux liens peuvent-ils partager un code — et quelqu'un peut-il deviner les codes privés ?
Les codes courts doivent être globalement uniques — jamais de collisions. Pour les liens privés, les codes ne doivent pas être devinables : une séquence prévisible laisserait un inconnu énumérer les URL privées une à une.
Les vrais entretiens sondent bien plus qu’une liste propre. Ces questions de périmètre séparent ceux qui interrogent le problème de ceux qui le récitent.
Traitez chaque estimation comme une pression qui justifie un composant : cache, file, partition, réplica, pool de workers ou chemin de repli.
QPS de lecture (redirection)
100M d'utilisateurs quotidiens (le dimensionnement à forte dominante de lecture ci-dessus) × ~1 redirection chacun par jour = 100M de redirections/jour100 000 000 de redirections ÷ 86 400 s dans une journée ≈ 1 160 QPS en moyenne · rafales virales ×5-10 ≈ 5-10K QPS au pic
Le cache + le CDN doivent absorber le pic — la base de données ne sert jamais le chemin critique de redirection.
QPS d'écriture (création)
~1 M de nouveaux liens par jour1,000,000 ÷ 86,400 s ≈ 12 écritures/s
Les écritures sont triviales, donc aucun passage à l'échelle en écriture n'est nécessaire. Le seul risque côté écriture est la bagarre sur l'allocation des codes, pas les insertions de lignes.
Stockage total
1 Md de liens × ~1 KB par ligne (code, URL longue, propriétaire, horodatages, TTL)10⁹ × 1 KB ≈ 1 TB
Tient confortablement dans un stockage partitionné ; l'index short_code est le véritable working set.
Espace de codes
codes base62 de 7 caractères (62 caractères par position)62⁷ ≈ 3.5 × 10¹² codes contre 10⁹ liens nécessaires → ~3,500× de marge
Les codes ne s'épuisent jamais — le vrai risque est la prévisibilité (codes énumérables), pas l'épuisement.
Taille du cache
On suppose que ~20 % des liens servent ~80 % des lectures (Pareto)20% × 1 TB ≈ 200 GB
Faisable sur un cluster Redis modeste. Les liens viraux les plus chauds sont aussi posés sur l'edge du CDN.
Exemple de décision
Les chiffres pointent dans une seule direction. Les lectures dépassent les écritures d'environ 100 pour 1, et culminent à 5-10K redirections par seconde, chacune avec moins de 100 ms pour répondre. Donc la redirection est le seul chemin qui vaille la peine d'être optimisé.
Répondre aux redirections depuis un cache d'abord — Redis, plus le CDN pour les liens les plus chauds. Ainsi la base de données n'est jamais sur le chemin chaud. Pour créer des liens, un petit service de clés remet à chaque serveur d'API un lot de codes uniques pré-fabriqués, si bien qu'une création ne se bat jamais sur un compteur partagé. Les clics sont comptés en déposant un événement sur un stream. La redirection n'attend jamais l'analytics.
Ce que je ne ferais PAS : hacher l'URL longue pour fabriquer le code et réessayer chaque fois que deux URL entrent en collision. Sous charge, ces réessais s'accumulent et créer un lien devient une loterie. Distribuer des codes uniques pré-fabriqués rend les collisions impossibles au lieu de simplement improbables.
Si des analytics par clic précises deviennent indispensables, je passerais des redirections 301 aux 302. Alors les navigateurs cessent de mettre le saut en cache, donc chaque clic atteint mes serveurs et est compté. J'accepte le petit surcroît de latence.
D’abord une image complète, puis chaque chemin comme son propre schéma — le chemin d’écriture et le chemin de lecture portent un trafic différent et justifient des composants différents.
Image complète
Commencez par la version simple : une image, chaque composant et relation. Pointillé = asynchrone, hors du chemin critique. Un cache miss se rabat sur la base de données et remplit à nouveau le cache.
Chemin 1
Le KGS distribue des plages de codes uniques pré-générées, si bien que les créations n'entrent jamais en collision et ne bloquent jamais sur un counter partagé.
Chemin 2
Un cache miss se rabat sur la base de données et remplit à nouveau le cache ; les événements de clic vont vers le flux analytique hors chemin.
Avant d’optimiser, rendez le contrat inspectable : endpoints, entités, propriété, retries et état.
POST/urls
req{ long_url, custom_alias?, expires_at? }
rés200 { short_url, expires_at } · 409 alias déjà pris · 400 URL invalide
Idempotent par (owner, long_url) : les resoumissions renvoient le short_url existant au lieu de générer un nouveau code.
GET/{short_code}
rés301/302 + Location: long_url · 404 code inconnu · 410 expiré
301 permet aux navigateurs de mettre la redirection en cache (moins d'accès à l'origine, perd l'analytique de clics) ; 302 fait passer chaque clic par vos serveurs (conserve l'analytique, ajoute un saut). Le choix dépend de l'exigence analytique — dites-le à voix haute.
Entités principales
ShortLinkshort_code (PK) · long_url · owner_id · created_at · expires_at · is_active
Partitionner par short_code pour qu'une redirection ne touche qu'une seule partition ; un index inversé optionnel long_url → short_code permet la déduplication à la création.
Useruser_id (PK) · email · created_at
Choisissez une voie pour le dernier tiers de l’entretien. Chaque voie vous donne le sujet, la question de l’examinateur à laquelle répondre, et le mode d’échec à éviter.
Comment garantir que deux liens n'obtiennent jamais le même code — counter + base62, ou hachage ? Pourquoi celui-là ?
Pré-générez les codes ; ne hachez pas. Un service séparé fabrique des codes uniques à l'avance et donne à chaque serveur API sa propre plage à distribuer. Deux serveurs ne peuvent pas choisir le même code, et personne n'a besoin de consulter la base d'abord — même pendant une grosse campagne. Le hachage ne fait que rendre les collisions rares, et chaque collision coûte une nouvelle tentative au pire moment de la charge.
Hacher l'URL en espérant que les collisions sont rares, sans expliquer la garantie d'unicité.
Déroulez une redirection de bout en bout : où le cache est-il touché, que se passe-t-il en cas de miss, et quand la base de données est-elle réellement sollicitée ?
Lisez le code depuis Redis d'abord. Un hit de cache répond en quelques millisecondes et ne touche jamais la base ; un miss lit une fois, puis réapprovisionne le cache. Les liens les plus chauds siègent aussi sur l'edge du CDN. Quand un lien est tué ou reciblé, n'attendez pas le TTL — supprimez-le de Redis et purgez la copie du CDN tout de suite, pour que le changement prenne effet en quelques secondes.
Lire la base de données à chaque redirection — le chemin critique doit être cache-first.
Quel statut de redirection renvoyez-vous, et quel effet ce choix a-t-il sur la mise en cache navigateur et vos données de clics ?
Utilisez 302 ici, parce qu'on doit compter chaque clic. Un 302 force le navigateur à redemander au serveur à chaque fois, donc chaque clic est vu — le coût, c'est un saut de plus. Un 301 laisse le navigateur mettre la redirection en cache pour toujours : plus rapide, mais les clics répétés deviennent invisibles. Puisque compter les clics est une exigence, le 302 l'emporte.
En choisir un arbitrairement — ce choix EST la décision analytique.
Comment enregistrer les clics pour 100 M de DAU sans ajouter de latence, et que se passe-t-il si le pipeline analytique prend du retard ?
La redirection dépose un événement de clic sur un flux durable comme Kafka et répond immédiatement — le comptage se fait après, à côté. Si ce pipeline prend du retard, les comptes se périment un temps, mais les redirections ne ralentissent jamais. Des chiffres périmés sont un compromis acceptable ; des redirections lentes, non.
Écrire l'analytique de manière synchrone à l'intérieur de la redirection.
Un seul lien absorbe soudain 10 % de tout le trafic — qu'est-ce qui casse en premier, et comment le cache et le CDN l'absorbent-ils ?
Un seul lien viral surcharge l'unique shard de cache qui le détient, bien avant que la base ne s'en aperçoive. Servez-le depuis l'edge du CDN avec un TTL court, pour que des millions de hits soient absorbés avant de nous atteindre. Les serveurs API peuvent aussi le garder en mémoire locale comme secours. Quelle que soit l'intensité du pic d'un lien, le trafic vers l'origine reste plat.
Supposer que le trafic est réparti uniformément — les clés chaudes sont la vraie charge.
Expliquez service de liens courts à voix haute et obtenez une évaluation IA de votre explication.