Concevoir un service de raccourcissement d'URL

A. Stratégie de génération d'URL courtes 1. Choix basé sur les exigences - Nouvelles créations : 100M/mois ≈ 3,3M/jour ≈ 38,6 créations/sec en moyenne. - Lectures à raison de 100:1 ≈ 3,3 milliards/mois ≈ 1 270 lectures/sec en moyenne, avec des pics probablement 10 à 50 fois plus élevés. - Nous avons besoin d'identifiants compacts, globalement uniques, avec une recherche très rapide. 2. Approche de génération de code J'utiliserais un service de génération d'ID déterministe plus un encodage Base62. Flux : - Un ID numérique globalement unique est généré. - Cet entier est encodé en Base62 à l'aide des caractères [0-9a-zA-Z]. - Exemple : 125 -> « 21 » en Base62. Pourquoi cette approche : - Aucun risque de collision si les ID sont uniques. - Très rapide à générer. - Facile à exploiter par rapport à la vérification de collision de codes aléatoires. - Croissance prévisible de la longueur du code. 3. Conception du générateur d'ID Option préférée : - Utiliser un générateur d'ID 64 bits de style Snowflake ou un allocateur de plages centralisé. - Les champs d'ID peuvent inclure l'horodatage + l'ID de la machine + la séquence, ou nous pouvons allouer des plages monotones croissantes aux serveurs d'applications. Deux bonnes implémentations : - ID de type Snowflake : décentralisés, haut débit, faible coordination. - Allocation de plages à partir d'un magasin de métadonnées : chaque nœud d'écriture loue un bloc d'ID, par exemple 1 million d'ID à la fois. Je préfère l'allocation de plages pour la simplicité car le débit d'écriture est modeste. Chaque serveur d'écriture peut générer des ID localement à partir de sa plage louée, évitant ainsi une dépendance centrale critique. 4. Schéma d'encodage et longueur attendue Capacité Base62 : - 62^6 ≈ 56,8 milliards - 62^7 ≈ 3,52 billions Liens totaux sur 5 ans : - 100M/mois * 60 mois = 6 milliards de liens Donc, 6 caractères Base62 ne suffisent pas pour une marge à long terme si les ID sont utilisés de manière dense globalement, mais 7 caractères sont plus que suffisants. Longueur attendue : - Commencer par 6 caractères pour le début du cycle de vie si désiré. - En pratique, standardiser sur 7 caractères pour simplifier l'implémentation et éviter les changements de longueur dans les attentes des utilisateurs. 5. Gestion des collisions Avec des ID uniques déterministes : - Aucune collision au niveau du code. - La contrainte d'unicité de la base de données sur `short_code` fournit un filet de sécurité final. - Si un doublon très rare est observé en raison d'un bug logiciel ou d'une mauvaise configuration de l'ID, régénérer à partir d'un nouvel ID et alerter. 6. Stratégie d'épuisement - Base62 à 7 caractères offre 3,52 billions de combinaisons, bien au-delà des 6 milliards nécessaires en 5 ans. - Si l'échelle future augmente considérablement, prendre en charge les codes à 8 caractères de manière transparente. - Le service de redirection doit traiter la longueur du code comme variable, donc aucun problème de migration. 7. Alias personnalisés optionnels Si le produit prend en charge les alias définis par l'utilisateur : - Stocker dans la même table de mappage avec unicité appliquée. - Réserver les mots bloqués et les termes abusifs. - Appliquer des limites de débit plus strictes car les alias personnalisés sont un point de contention. B. Stockage des données 1. Choix de la base de données principale Utiliser un magasin clé-valeur distribué et hautement disponible pour le mappage d'URL, tel que : - DynamoDB / Bigtable / Cassandra Pourquoi : - Le modèle d'accès principal est une simple recherche par clé `short_code`. - Nécessite une mise à l'échelle horizontale, une haute disponibilité et des lectures multi-répliques. - Les écritures sont modestes, les lectures sont dominantes. - L'accès clé-valeur est idéal pour une latence de redirection inférieure à 50 ms. Je choisirais un stockage de type DynamoDB ou Cassandra conceptuellement : - Partitionner par hachage de `short_code`. - Répliquer entre les zones de disponibilité. - Optimiser pour des lectures ponctuelles à faible latence. 2. Magasins secondaires - Base de données relationnelle pour les métadonnées du plan de contrôle, la facturation, les utilisateurs, les domaines, les politiques. - Stockage d'objets + lac de données pour l'analytique/les journaux de clics. - Magasin de recherche/indexation optionnel si les administrateurs ont besoin de requêtes par créateur, date, balises, etc. 3. Conception du schéma Table de mappage principale : - `short_code` (PK) - `destination_url` - `created_at` - `expires_at` (peut être nul) - `owner_id` (peut être nul) - `status` (actif, désactivé, supprimé) - `redirect_type` (301/302) - `checksum` ou `normalized_url` haché (optionnel) - Pointeur de métadonnées (optionnel) Table de déduplication optionnelle si le produit souhaite que la même URL longue renvoie la même URL courte par locataire : - `dedup_key` = hachage(`tenant_id` + `canonicalized_url`) - `short_code` Ceci est facultatif ; de nombreux raccourcisseurs d'URL ne dédupliquent pas globalement car les sémantiques diffèrent selon l'utilisateur, la campagne ou les besoins analytiques. 4. Estimation du stockage sur 5 ans Liens totaux : - 6 milliards d'enregistrements Estimation approximative par enregistrement : - `short_code` : ~8 octets équivalent brut - `destination_url` : moyenne de 200 octets supposée - Horodatages/statut/indicateurs : ~24 octets - Frais de réplication/versionnement/indexation : substantiels dans les systèmes réels - Frais du moteur de stockage : environ 350–500 octets effectifs par enregistrement dans la base de données principale supposés En utilisant 400 octets/enregistrement : - 6 milliards * 400 octets = 2,4 To de données logiques brutes Avec un facteur de réplication de 3 : - 7,2 To Ajouter les index, les frais de compaction, les tombstones, les métadonnées, la marge opérationnelle : - Prévoir 10 à 15 To de stockage principal sur 5 ans Les journaux d'analytique/clics sont beaucoup plus volumineux que les mappages. À 100 lectures par écriture : - 600 milliards de redirections sur 5 ans Si chaque événement de journal de clics faisait en moyenne seulement 100 octets compressés, cela représente ~60 To compressés, probablement beaucoup plus avec des champs plus riches. Par conséquent, les journaux doivent aller dans un stockage d'objets bon marché, pas dans la base de données de service. 5. Stratégie de partitionnement/sharding Sharding de la table principale : - Clé de partition : `short_code` ou hachage(`short_code`) - Distribution uniforme car les ID sont encodés à partir d'ID numériques bien distribués ou d'ID de plage mélangés de manière appropriée Note importante : - Les ID purement séquentiels peuvent créer des partitions chaudes dans certaines bases de données si la localité des clés est importante. - Pour éviter cela, soit : 1. Hacher le `short_code` pour le placement de la partition, soit 2. Utiliser des ID avec suffisamment d'entropie dans les bits inférieurs, soit 3. Préfixer avec des bits de shard avant l'encodage Base62 Je partitionnerais explicitement par hachage sur `short_code` pour assurer une distribution uniforme. C. Architecture du chemin de lecture 1. Aperçu du chemin de lecture Flux de requêtes : - L'utilisateur accède à https://sho.rt/abc1234 - Le DNS achemine vers le CDN/edge le plus proche - Le CDN transmet au service de redirection régional s'il n'y a pas de succès de cache - Le service de redirection vérifie le cache en mémoire/Redis - En cas de manque de cache, lire dans le magasin clé-valeur distribué - Retourner HTTP 301/302 avec l'en-tête `Location` - Émettre de manière asynchrone un événement de clic vers le pipeline d'analytique 2. Atteindre une latence p95 < 50 ms Le chemin de redirection doit être extrêmement léger. Exemple de budget de latence : - Routage Edge/CDN : petit, géographiquement local - Traitement de l'application : 1–3 ms - Succès du cache Redis/en mémoire : 1–5 ms - Chemin de manque de DB dans la région : 5–15 ms typique - Le p95 total inférieur à 50 ms est réalisable avec un service régional et une mise en cache agressive 3. Couches de mise en cache Couche 1 : Mise en cache CDN/Edge - Mettre en cache les réponses de redirection pour les liens populaires en périphérie. - Très efficace car de nombreux liens courts populaires sont consultés à plusieurs reprises. - Utiliser des en-têtes `cache-control` avec TTL, par exemple de quelques minutes à quelques heures selon la mutabilité. - Si les liens peuvent être désactivés rapidement, choisir un TTL plus court ou un support de purge. Couche 2 : Cache local de l'application - Chaque nœud de redirection conserve un cache LRU des mappages populaires. - Latence ultra-faible, évite le saut réseau vers Redis. - Idéal pour les codes les plus fréquemment demandés. Couche 3 : Cache distribué (Redis/Memcached) - Cache partagé pour la flotte régionale. - Stocke `short_code` -> `destination_url`, statut, type de redirection. - Le TTL peut être long pour les liens immuables ; plus court pour les liens immuables/gérés par l'administrateur. 4. Stratégie de réplication pour les lectures - Répliques Multi-AZ au sein de chaque région. - Servir les lectures à partir des répliques de stockage de la région locale. - Actif-actif entre plusieurs régions pour le trafic mondial. - Utiliser le geo-DNS ou Anycast pour acheminer vers la région saine la plus proche. 5. Stratégie de population du cache - Lecture directe en cas de manque : l'application récupère depuis la DB, peuple Redis et le cache local. - Mise en cache négative pour les codes inexistants/désactivés avec un TTL court pour absorber les abus et les erreurs de frappe. - Préchauffage du cache pour les liens tendance si connus grâce à l'analytique. 6. Sémantique de redirection - 302 par défaut si la destination peut changer ou si les politiques d'analytique/de suivi l'exigent. - 301 pour les liens permanents où les clients et les CDN peuvent mettre en cache de manière agressive. - La décision du produit peut exposer les deux options. 7. Gestion des abus sur le chemin de lecture - Limiter le débit par IP / ASN / jeton pour les requêtes à haut débit suspectes. - WAF et filtres de bots au niveau du CDN. - Protéger l'origine contre la recherche par force brute de codes courts. D. Architecture du chemin d'écriture 1. Aperçu du chemin d'écriture Flux de requêtes : - Le client envoie l'URL longue et les métadonnées/alias personnalisé optionnels. - La passerelle API authentifie et limite le débit. - La validation et la normalisation de l'URL se font dans la couche d'application sans état. - L'application obtient/génère un code court. - Persister le mappage dans le magasin clé-valeur principal. - Peuplage des caches de manière asynchrone ou synchrone pour une disponibilité immédiate. - Émettre un événement de création vers une file d'attente pour l'analytique, la détection d'abus et l'indexation en aval. 2. Capacité 100 millions/mois n'est pas élevé pour les systèmes modernes : - Moyenne d'environ 39 écritures/sec - Même une rafale de 100x ne représente que quelques milliers d'écritures/sec Les principaux objectifs sont donc la fiabilité, l'idempotence et la simplicité opérationnelle plutôt qu'un débit d'écriture extrême. 3. Étapes de validation - Valider la syntaxe de l'URL. - Appliquer les protocoles autorisés, généralement http/https uniquement. - Analyse asynchrone optionnelle de navigation sécurisée ou de logiciels malveillants ; si un risque est détecté, désactiver le lien. - Canonicaliser l'URL pour une logique de déduplication optionnelle. 4. Mise en file d'attente et travail asynchrone Utiliser une file d'attente ou un journal durable tel que Kafka/SQS/PubSub pour les effets secondaires : - Événement d'analytique pour la création de nouveau lien - Détection d'abus/escroquerie/hameçonnage - Préchauffage du cache - Indexation de la recherche - Pipeline de notification/audit Le chemin critique ne doit inclure que ce qui est nécessaire pour créer le mappage et retourner l'URL raccourcie. 5. Modèle de cohérence Pour la réponse de création, utiliser la cohérence après création pour le nouveau code court : - Une fois que l'API renvoie un succès, la redirection doit fonctionner immédiatement. Comment : - Persister le mappage vers le quorum/leader dans la DB principale avant d'accuser réception. - Optionnellement, écrire dans Redis après la validation de la DB. - Le chemin de redirection se rabat sur la DB en cas de manque de cache, donc le décalage de propagation du cache ne compromet pas la correction. 6. Idempotence Prendre en charge les clés d'idempotence pour les clients API afin d'éviter les doublons de liens lors des nouvelles tentatives. - Stocker `request_id` -> `short_code` pour une durée limitée dans un magasin rapide. - Particulièrement utile pour les scénarios de nouvelle tentative mobile/réseau. 7. Limitation du débit - Quotas par utilisateur/clé API pour contrôler les abus. - Limites plus strictes sur les requêtes d'alias personnalisés. - Garde-fous globaux pour empêcher l'amplification des écritures induite par les attaques. E. Fiabilité et tolérance aux pannes 1. Objectif de disponibilité : 99,9 % 99,9 % de disponibilité autorise environ 43,8 minutes d'indisponibilité/mois. Ceci est réalisable avec un déploiement multi-AZ et un basculement régional. 2. Gestion des pannes Panne de nœud : - Nœuds d'application sans état derrière des équilibreurs de charge ; remplacer automatiquement les instances non saines. - Les caches locaux sont jetables. - Redis déployé en cluster haute disponibilité/mode sentinel. Panne d'AZ : - Couche d'application déployée sur au moins 3 AZ. - DB principale répliquée entre les AZ. - L'équilibreur de charge supprime l'AZ non saine. Panne régionale/DC : - Service de lecture actif-actif entre plusieurs régions. - Données répliquées entre régions de manière asynchrone ou quasi synchrone selon les capacités de la DB. - Le gestionnaire DNS/trafic bascule les utilisateurs vers la région saine. 3. Durabilité des données - Facteur de réplication de la DB principale de 3 entre les AZ. - Instantanés/sauvegardes périodiques vers le stockage d'objets. - Archivage des journaux WAL/commit si pris en charge. - Copies de sauvegarde inter-régionales pour la reprise après sinistre. 4. Stratégie de sauvegarde et de récupération - Instantanés complets quotidiens plus sauvegardes incrémentielles. - Récupération à un instant T pour suppression/corruption accidentelle. - Exercices de restauration réguliers dans un environnement de staging pour vérifier le RTO/RPO. - Rétention des sauvegardes alignée sur l'exigence d'accessibilité sur 5 ans et les besoins de conformité. Objectifs raisonnables : - RPO : minutes à 1 heure selon le modèle de réplication inter-régionale - RTO : moins d'une heure pour le basculement régional, plus long pour la reconstruction complète du stockage, mais cela devrait être rare 5. Stratégie d'invalidation de cache Si les liens sont principalement immuables, la mise en cache est simple. Pour les liens modifiables (désactiver/changer la destination/expiration) : - Mettre à jour la DB d'abord. - Publier un événement d'invalidation. - Supprimer la clé Redis et les entrées du cache local. - Purger le cache CDN si la mise en cache en périphérie est utilisée pour ce code. - Utiliser un TTL borné afin que le cache obsolète se rétablisse même si l'invalidation échoue. 6. Protection contre la corruption des données et les abus - Contraintes d'unicité de la DB sur `short_code`. - Sommes de contrôle/champs de version pour les enregistrements. - Journaux d'audit pour les actions des administrateurs. - Suppression logique ou état désactivé au lieu de suppression physique lorsque cela est possible. - Outils d'analyse des logiciels malveillants/hameçonnage et de retrait. F. Compromis clés 1. Génération d'ID déterministe vs codes courts aléatoires Options : - ID séquentiels/basés sur des plages déterministes : simples, pas de collisions, compacts, rapides. - Codes aléatoires : moins prévisibles/énumérables mais nécessitent des vérifications de collision et plus de complexité. Choix : - Je choisis des ID déterministes encodés en Base62. Pourquoi : - Plus simple, plus rapide et plus sûr opérationnellement pour cette échelle. - Sans collision sans boucles de nouvelle tentative. - Meilleur ajustement car le débit est modeste et le principal défi est la latence de lecture. Coût : - Les codes peuvent être plus énumérables/prévisibles. Atténuation : - Limitation du débit, détection de bots, alias optionnels plus longs/non séquentiels pour les liens sensibles. 2. Cohérence plus forte à la création vs cohérence éventuelle partout Options : - La cohérence éventuelle pourrait réduire la latence d'écriture et simplifier les écritures multi-régions. - L'accusé de réception fort après une écriture durable garantit qu'un URL court retourné fonctionne immédiatement. Choix : - Cohérence forte pour le chemin de création de lien unique dans une région d'origine ; cohérence éventuelle pour les caches secondaires et la propagation inter-régionale. Pourquoi : - Meilleure expérience utilisateur : une fois que l'API renvoie, la redirection doit réussir. - Le volume d'écriture est suffisamment faible pour que nous n'ayons pas besoin de relâcher la cohérence sur le chemin critique d'écriture. 3. Mise en cache agressive en périphérie vs invalidation rapide Options : - Les TTL CDN longs maximisent les performances de lecture et réduisent les coûts d'origine. - Les TTL courts rendent les opérations de désactivation/mise à jour plus rapides. Choix : - TTL modéré avec purge explicite pour les liens modifiables/gérés par l'administrateur ; TTL plus long pour les liens immuables. Pourquoi : - La plupart des URL raccourcies sont effectivement immuables, donc la mise en cache offre des avantages majeurs en termes de latence et de coût. - Mais les suppressions pour abus nécessitent une invalidation raisonnablement rapide. 4. Simplicité vs richesse analytique sur le chemin de redirection Options : - La journalisation synchrone des clics garantit des analyses immédiates mais ajoute de la latence et un couplage des défaillances. - L'émission d'événements asynchrones maintient les redirections rapides mais les analyses peuvent être en retard ou perdre de petites quantités lors des défaillances. Choix : - Analytique asynchrone. Pourquoi : - Le SLA strict du produit est la latence de redirection et la disponibilité, pas une analytique en temps réel sans perte. - Le chemin de redirection ne doit jamais être bloqué par les systèmes de journalisation en aval. Architecture récapitulative - Génération de code court : ID uniques 64 bits basés sur des plages louées ou de style Snowflake encodés en Base62, codes standard à 7 caractères. - Magasin principal : base de données KV distribuée, partitionnée par hachage sur `short_code`, RF=3, multi-AZ. - Chemin de lecture : CDN + cache local + Redis + repli sur magasin KV ; lectures actif-actif multi-régions. - Chemin d'écriture : API sans état + écriture DB durable + file d'attente asynchrone pour les effets secondaires ; idempotence et limites de débit. - Fiabilité : multi-AZ, réplication inter-régionale, sauvegardes, événements d'invalidation de cache, basculement DNS. - Cette conception prend en charge confortablement 100 millions de nouvelles URL/mois, un ratio de lecture de 100:1, une rétention de 5 ans, une disponibilité de 99,9 % et des redirections < 50 ms p95.

## Conception d'un service de raccourcissement d'URL Ce document décrit la conception d'un service de raccourcissement d'URL capable de gérer 100 millions de nouvelles URL par mois, un ratio lecture/écriture de 100:1, une rétention des données de 5 ans, une disponibilité de 99,9 % et une latence de redirection inférieure à 50 ms au 95e percentile. ### A. Stratégie de génération d'URL courtes **Schéma d'encodage** : Nous utiliserons l'encodage Base62 (0-9, a-z, A-Z). Ce schéma est sûr pour les URL et fournit une représentation compacte pour les identifiants uniques. **Longueur d'URL attendue** : Sur 5 ans, le service doit prendre en charge 100 millions d'URL/mois * 12 mois/an * 5 ans = 6 milliards d'URL uniques. Une chaîne Base62 de 6 caractères fournit 62^6 = 56 800 235 584 clés uniques possibles, ce qui est plus que suffisant pour 6 milliards d'URL. Nous commencerons avec 6 caractères et aurons la flexibilité de passer à 7 caractères (62^7 ≈ 352 milliards de clés) si l'espace de clés s'épuise. **Méthode de génération** : Nous emploierons un **Service de Génération de Clés (KGS)**. Ce service sera responsable de la génération d'identifiants numériques uniques et croissants de manière monotone. Ces identifiants seront ensuite encodés en Base62 pour produire les codes d'URL courtes. Le KGS peut utiliser un algorithme de génération d'ID distribué (par exemple, un générateur d'ID Snowflake modifié ou un service dédié qui incrémente un compteur et pré-alloue des blocs d'ID à plusieurs instances KGS pour éviter la contention). Cette approche garantit l'unicité et évite les collisions par conception, éliminant le besoin de recherches dans la base de données lors de la génération de clés. **Gestion des collisions** : Avec le KGS générant des ID numériques uniques, les collisions sont intrinsèquement évitées. Chaque ID généré est unique, et son encodage Base62 sera également unique. Si une stratégie de génération aléatoire était choisie, la gestion des collisions impliquerait de vérifier l'existence dans la base de données et de régénérer en cas de collision, ce qui ajoute de la latence et de la complexité. **Épuisement de l'espace de clés** : Comme discuté, une clé Base62 de 6 caractères offre un espace suffisant pour 6 milliards d'URL. Si le service dépasse ce nombre, l'extension de la longueur de la clé à 7 caractères fournira une capacité considérablement plus grande. Le KGS sera conçu pour gérer cette transition de manière transparente en générant des ID plus longs si nécessaire. ### B. Stockage des données **Sélection de la base de données** : Pour le mappage principal `code_court` vers `url_longue`, nous utiliserons un **magasin clé-valeur NoSQL distribué** comme **Apache Cassandra**. Cassandra est hautement évolutif, tolérant aux pannes et optimisé pour les lectures et écritures à haut volume et faible latence, ce qui le rend idéal pour notre charge de travail à forte lecture. Sa nature distribuée et ses capacités de réplication intégrées garantissent une haute disponibilité et la durabilité des données. **Estimation du stockage** : * URL totales sur 5 ans : 6 milliards. * Chaque entrée stockera : * `code_court` : 6-7 caractères (environ 7 octets) * `url_longue` : 100 caractères en moyenne (environ 100 octets) * `créé_le` : Horodatage (8 octets) * `expire_le` : Horodatage (8 octets, pour une rétention de 5 ans) * `nombre_clics` : Compteur (8 octets) * `id_utilisateur` (optionnel) : par exemple, 36 octets pour UUID * Total par entrée (estimation prudente, frais généraux inclus) : ~150 octets. * Stockage brut total : 6 milliards d'URL * 150 octets/URL = 900 milliards d'octets = 0,9 To. * Avec un facteur de réplication de 3 (courant pour Cassandra pour une haute disponibilité) : 0,9 To * 3 = **2,7 To**. **Conception du schéma (Cassandra)** : ```sql CREATE TABLE short_urls ( short_code text PRIMARY KEY, -- Clé de partition pour une distribution uniforme long_url text, created_at timestamp, expires_at timestamp, click_count counter, user_id text ); ``` **Stratégie de partitionnement/sharding** : Cassandra gère intrinsèquement le partitionnement et le sharding des données en fonction de la clé primaire (`code_court`). Le `code_court` Base62 assure une bonne distribution des données sur les nœuds du cluster, empêchant les points chauds et garantissant une récupération efficace des données. Nous configurerons Cassandra avec un facteur de réplication de 3 sur plusieurs centres de données ou zones de disponibilité pour la tolérance aux pannes et la haute disponibilité. ### C. Architecture du chemin de lecture **Débit** : Avec 100 millions d'écritures/mois et un ratio lecture/écriture de 100:1, nous nous attendons à 10 milliards de lectures/mois, soit en moyenne environ 3 858 lectures/seconde. Les charges de pointe pourraient être 5 à 10 fois plus élevées, atteignant 20 000 à 40 000 lectures/seconde. **Composants de l'architecture** : 1. **Équilibreur de charge (par exemple, AWS ELB, Nginx)** : Distribue les requêtes HTTP entrantes pour les URL courtes sur plusieurs instances du service de redirection. 2. **Cache distribué (par exemple, cluster Redis)** : C'est essentiel pour répondre aux exigences de latence et de débit. Le cache stockera les mappages `code_court` vers `url_longue`. Compte tenu du ratio lecture/écriture de 100:1, un taux de succès de cache très élevé (par exemple, 95 %+) est attendu, réduisant considérablement la charge sur la base de données. * **Invalidation du cache** : Les mappages d'URL courtes sont généralement immuables. Les entrées du cache peuvent avoir un TTL très long ou être permanentes. Si une `url_longue` doit être mise à jour (rare), une invalidation explicite du cache serait déclenchée. 3. **Service de redirection (Serveurs d'application)** : Une flotte de serveurs d'application sans état (par exemple, exécutant Go, Java ou Node.js) derrière l'équilibreur de charge. * Lors de la réception d'une requête d'URL courte, le service vérifie d'abord le cache Redis. * En cas de succès du cache, il émet immédiatement une redirection HTTP 301 (Permanente) ou 302 (Temporaire) vers l'`url_longue`. * En cas d'échec du cache, il interroge la base de données Cassandra pour le `code_court`. * Une fois récupéré de Cassandra, le mappage est stocké dans Redis pour les requêtes futures, puis la redirection est émise. * Les nombres de clics sont mis à jour de manière asynchrone (par exemple, en envoyant des messages à une file d'attente Kafka pour traitement par un service d'analyse distinct ou en incrémentant directement un compteur dans Cassandra, qui prend en charge les incréments atomiques). 4. **Base de données (Cluster Cassandra)** : Sert de stockage persistant pour tous les mappages d'URL et gère les échecs de cache. Sa nature distribuée et sa réplication garantissent une haute disponibilité et une récupération de données à faible latence pour l'échelle requise. **Stratégies de réplication** : * **Serveurs d'application** : Plusieurs instances déployées dans différentes zones de disponibilité, gérées par des groupes d'auto-scaling. * **Cache** : Cluster Redis avec des configurations maître-réplique pour chaque shard, garantissant la haute disponibilité et la redondance des données. * **Base de données** : La réplication native multi-centres de données de Cassandra (par exemple, facteur de réplication 3 sur au moins deux centres de données) offre de solides capacités de tolérance aux pannes et de reprise après sinistre. ### D. Architecture du chemin d'écriture **Débit** : 100 millions de nouvelles URL par mois se traduisent par une moyenne d'environ 38 écritures/seconde. Les charges de pointe pourraient atteindre 300 à 400 écritures/seconde. **Composants de l'architecture** : 1. **Équilibreur de charge** : Distribue les requêtes entrantes pour le raccourcissement de nouvelles URL vers les instances du service d'écriture. 2. **Service d'écriture (Passerelle API/Serveurs d'application)** : * Reçoit l'`url_longue` de l'utilisateur. * Appelle le **Service de Génération de Clés (KGS)** pour obtenir un `code_court` unique. * Construit le mappage `code_court` vers `url_longue`. * Publie ce mappage dans une **File d'attente de messages (par exemple, Apache Kafka)**. Cela découple le service d'écriture de la base de données, fournit une mise en mémoire tampon et améliore la fiabilité. * Retourne le `code_court` généré à l'utilisateur. 3. **Service de Génération de Clés (KGS)** : Comme décrit dans la section A, ce service génère des ID numériques uniques et les encode en codes `code_court` Base62. Il peut pré-générer des blocs de clés pour minimiser la latence pendant les périodes de pointe d'écriture. 4. **Processus de travail (Consommateurs)** : Un pool de processus de travail consomme les messages de la file d'attente Kafka. * Pour chaque message, le travailleur écrit le `code_court` et l'`url_longue` dans la **base de données Cassandra**. * Il écrit ensuite immédiatement le mappage dans le **Cache Redis** pour garantir que l'URL courte nouvellement créée soit instantanément disponible pour les lectures. 5. **Base de données (Cluster Cassandra)** : Stocke de manière persistante les nouveaux mappages d'URL. **Considérations de cohérence** : * Pour le mappage `code_court` vers `url_longue`, une forte cohérence est souhaitée. En écrivant dans Cassandra avec des niveaux de cohérence appropriés (par exemple, `QUORUM`) et en remplissant ensuite immédiatement le cache, nous garantissons qu'une fois qu'un code court est renvoyé à l'utilisateur, il se résoudra correctement. * L'utilisation d'une file d'attente de messages assure une cohérence éventuelle pour la couche de persistance, mais la mise à jour immédiate du cache garantit que le chemin de lecture est cohérent pour les nouvelles URL. Si la mise à jour du cache échoue, le chemin de lecture atteindra finalement la base de données, qui sera cohérente. ### E. Fiabilité et tolérance aux pannes **Pannes de nœuds** : * **Serveurs d'application (Services de redirection et d'écriture)** : Sans état et déployés dans des groupes d'auto-scaling à travers plusieurs zones de disponibilité. Les équilibreurs de charge acheminent automatiquement le trafic loin des instances défaillantes, et de nouvelles instances sont lancées pour les remplacer. * **Cache distribué (Cluster Redis)** : Configuré avec une réplication maître-réplique. Si un nœud maître tombe en panne, une réplique est automatiquement promue maître, minimisant les temps d'arrêt et la perte de données pour les éléments mis en cache. * **Base de données (Cluster Cassandra)** : Conçu pour une haute disponibilité avec un facteur de réplication de 3 sur plusieurs nœuds et centres de données. Si un nœud tombe en panne, ses données sont disponibles sur d'autres répliques, et Cassandra gère automatiquement la réparation des données et le remplacement du nœud défaillant. * **Service de Génération de Clés (KGS)** : Déployé avec plusieurs instances derrière un équilibreur de charge. Le mécanisme sous-jacent de génération d'ID distribué (par exemple, en utilisant Zookeeper pour la coordination ou un compteur hautement disponible) garantit que des ID uniques peuvent toujours être générés même si certaines instances KGS échouent. * **File d'attente de messages (Kafka)** : Déployé sous forme de cluster avec réplication. Si un courtier tombe en panne, d'autres courtiers continuent de fonctionner et les données sont répliquées pour garantir aucune perte de message. **Pannes de centres de données** : L'ensemble du système sera déployé dans au moins deux centres de données géographiquement distincts ou plusieurs zones de disponibilité au sein d'une région. Les équilibreurs de charge seront configurés pour le basculement inter-zones/inter-régions. La réplication multi-centres de données de Cassandra garantit la durabilité et la disponibilité des données même si un centre de données entier devient indisponible. **Invalidation du cache** : Comme les mappages `code_court` vers `url_longue` sont largement immuables, l'invalidation explicite du cache est rarement nécessaire. Les entrées du cache peuvent avoir un TTL très long. Si une `url_longue` doit être mise à jour (par exemple, pour des raisons juridiques), le service d'écriture mettrait à jour la base de données, puis invaliderait/mettrait à jour explicitement l'entrée correspondante dans le cache Redis. **Stratégie de sauvegarde et de récupération** : * **Base de données** : Des instantanés réguliers et automatisés du cluster Cassandra seront pris et stockés dans un service de stockage d'objets hautement durable (par exemple, AWS S3, Google Cloud Storage). Ces sauvegardes permettent une récupération à un instant T en cas de corruption de données ou de suppression accidentelle. Les sauvegardes incrémentielles et les journaux de validation de Cassandra peuvent également être utilisés pour une récupération plus granulaire. * **Configuration** : Toutes les configurations d'infrastructure (Infrastructure as Code) et d'application seront versionnées (par exemple, Git) et déployées à l'aide de pipelines automatisés, permettant une restauration rapide des configurations de service. * **Surveillance et alertes** : Une surveillance complète (par exemple, Prometheus, Grafana) sera en place pour suivre l'état du système, les métriques de performance et les taux d'erreur. Des alertes automatisées informeront les équipes d'exploitation de toute anomalie ou défaillance, permettant une réponse et une récupération rapides. ### F. Principaux compromis 1. **Cohérence vs Disponibilité (pour le mappage `code_court` vers `url_longue`)** * **Compromis choisi** : Nous privilégions une forte cohérence pour le mappage principal `code_court` vers `url_longue`, tout en autorisant une cohérence éventuelle pour les données auxiliaires telles que les nombres de clics. * **Explication** : Le but fondamental d'un raccourcisseur d'URL est de rediriger de manière fiable une URL courte vers sa longue URL correcte. Un mappage incohérent (par exemple, rediriger vers la mauvaise URL ou ne pas rediriger) dégraderait gravement l'expérience utilisateur et briserait le contrat principal du service. Par conséquent, nous garantissons qu'une fois qu'un `code_court` est créé et renvoyé à l'utilisateur, il résout immédiatement vers la `url_longue` correcte. Ceci est réalisé en écrivant dans Cassandra avec des niveaux de cohérence forts (par exemple, `QUORUM`) et en remplissant immédiatement le cache Redis. La disponibilité est maintenue grâce à une réplication étendue et une architecture distribuée, garantissant que le service reste opérationnel même avec des exigences de forte cohérence pour le chemin critique. Les nombres de clics, cependant, peuvent tolérer de légers retards dans les mises à jour, rendant la cohérence éventuelle acceptable pour ces données non critiques. 2. **Simplicité vs Évolutivité/Performance (Stratégie de génération de clés)** * **Compromis choisi** : Nous avons opté pour un Service de Génération de Clés (KGS) dédié utilisant un compteur distribué et un encodage Base62, ce qui est plus complexe, par rapport à une approche plus simple de génération de chaînes Base62 aléatoires et de vérification des collisions. * **Explication** : Bien que la génération de chaînes aléatoires et la vérification des collisions dans la base de données soient plus simples à implémenter initialement, cela introduit plusieurs défis d'évolutivité et de performance. À mesure que l'espace de clés se remplit, la probabilité de collisions augmente, entraînant plus de tentatives et une latence plus élevée sur le chemin d'écriture. Ce modèle de lecture avant écriture peut devenir un goulot d'étranglement sous de fortes charges d'écriture. L'approche KGS choisie, bien que plus complexe à concevoir et à maintenir (nécessitant un générateur d'ID distribué), garantit des clés uniques sans collisions. Elle permet la pré-génération de blocs de clés, réduisant considérablement la latence d'acquisition de clés pour le service d'écriture. Cette complexité initiale est justifiée par la nécessité d'une génération de clés prévisible, performante et hautement évolutive sur la durée de vie de 5 ans du service, garantissant que le chemin d'écriture reste efficace et fiable à mesure que le système grandit.