Concevoir un service global de raccourcissement d'URL

Conception : Service mondial de raccourcissement d'URL 1. EXIGENCES ET ESTIMATIONS PRÉLIMINAIRES Exigences fonctionnelles : - Créer un lien court pour une URL longue donnée (avec alias personnalisé optionnel). - Rediriger les visiteurs du lien court vers l'URL d'origine (HTTP 301/302). - Analyses de base : clics totaux par lien, clics par jour sur les 30 derniers jours. Exigences non fonctionnelles : - 120 millions de nouveaux liens par mois, soit environ 46 écritures par seconde en moyenne, avec des pics autour de 200 par seconde. - 1,2 milliard de redirections par mois, soit environ 463 par seconde en moyenne, avec des pics allant de 5 000 à 50 000 par seconde pour les liens viraux. - 99,99 % de disponibilité des redirections. - Redirections mondiales à faible latence. - Liens valides pendant au moins 5 ans. - Analyses cohérentes à terme sous 10 minutes. - Prévention de base des abus. Estimation du stockage : - 120 millions de liens par mois multipliés par 60 mois (5 ans) égalent 7,2 milliards de liens. - Chaque enregistrement de lien d'environ 500 octets (code court, URL longue, métadonnées) représente environ 3,6 To de données de liens sur 5 ans. - Les données d'analyse sont supplémentaires mais gérables grâce à l'agrégation. 2. ARCHITECTURE DE HAUT NIVEAU Le système est composé des composants majeurs suivants : a) Passerelle API et équilibreur de charge : Point d'entrée pour tout le trafic. Gère la terminaison TLS, la limitation de débit, l'authentification pour la création de liens et le routage. Déployé dans plusieurs régions derrière un DNS global anycast ou un équilibreur de charge global (par exemple, AWS Global Accelerator ou Cloudflare). b) Service de création de liens : Service sans état qui gère les requêtes POST pour créer de nouveaux liens courts. Valide les entrées, génère ou réserve des codes courts, vérifie la disponibilité des alias personnalisés, applique des vérifications de base des abus et écrit dans la base de données principale. c) Service de redirection : Service sans état, optimisé en lecture, qui gère les requêtes GET pour les codes courts. Recherche d'abord le code court dans le cache, puis dans la base de données, et renvoie une redirection HTTP 301 ou 302. Émet également un événement de clic de manière asynchrone pour les analyses. d) Service d'analyse : Consomme les événements de clic à partir d'une file d'attente de messages, les agrège et stocke les décomptes quotidiens et totaux. Traite les requêtes d'analyse. e) Couche de cache : Cache distribué (clusters Redis ou Memcached) déployé dans chaque région pour servir les codes courts fréquemment utilisés avec une latence inférieure à la milliseconde. f) Base de données principale : Stocke les correspondances de liens canoniques. Une base de données distribuée comme Amazon DynamoDB, Google Cloud Spanner ou CockroachDB. g) File d'attente de messages : Kafka ou Amazon Kinesis pour la mise en mémoire tampon des événements de clic entre le service de redirection et le pipeline d'analyse. h) CDN / Couche Edge : Pour les liens les plus populaires, les réponses de redirection peuvent être mises en cache en périphérie du CDN (en utilisant 301 avec des en-têtes de cache appropriés ou des workers edge qui effectuent la recherche). Flux d'architecture : - Création de lien : Client -> Passerelle API -> Service de création de liens -> DB principale (écriture) -> Invalidation/remplissage du cache -> Retour de l'URL courte. - Redirection : Client -> CDN/Edge -> (cache manqué) -> Passerelle API -> Service de redirection -> Cache -> (cache manqué) -> DB -> Retour de la redirection 302. Émission asynchrone d'un événement de clic vers la file d'attente de messages. - Requête d'analyse : Client -> Passerelle API -> Service d'analyse -> DB d'analyse -> Retour des résultats. 3. MODÈLE DE DONNÉES ET STOCKAGE Table de correspondance des liens (Stockage principal - DynamoDB ou similaire) : - short_code (clé de partition) : chaîne, 7 caractères, par exemple "aB3x9Kz" - long_url : chaîne, l'URL d'origine, jusqu'à 2048 caractères - user_id : chaîne, optionnel, le créateur - custom_alias : booléen, s'il s'agissait d'un alias personnalisé - created_at : horodatage - expires_at : horodatage (created_at + 5 ans par défaut) - click_count : entier (compteur cohérent à terme, mis à jour périodiquement) - status : énumération (actif, désactivé, expiré) Pourquoi DynamoDB : Le modèle de recherche clé-valeur unique est parfaitement adapté. Il évolue horizontalement avec une latence constante à un chiffre en millisecondes. La clé de partition est le short_code, qui se distribue bien compte tenu de la nature aléatoire des codes générés. Stockage d'analyse : - Option A : Une table de séries temporelles dans DynamoDB ou Cassandra avec clé de partition = short_code et clé de tri = date (AAAA-MM-JJ), avec un attribut click_count. - Option B : Des décomptes quotidiens pré-agrégés stockés dans une table séparée, avec un TTL de 30 jours pour les lignes de granularité quotidienne. Schéma pour la table d'analyse quotidienne : - short_code (clé de partition) : chaîne - date (clé de tri) : chaîne, format AAAA-MM-JJ - click_count : entier - TTL : horodatage, 30 jours à partir de la date Cela permet des requêtes de plage efficaces : obtenir tous les décomptes quotidiens pour un short_code au cours des 30 derniers jours. Pour les décomptes totaux de clics, nous maintenons un compteur courant dans la table principale de correspondance des liens, mis à jour par le pipeline d'analyse. 4. STRATÉGIE DE GÉNÉRATION D'ID / DE JETON Exigences : 7,2 milliards de codes uniques sur 5 ans. En utilisant l'encodage base62 (a-z, A-Z, 0-9), un code de 7 caractères donne 62^7 = 3,5 billions de combinaisons possibles, ce qui est plus que suffisant. Approche : Plages d'ID pré-générées à l'aide d'un compteur distribué ou d'une allocation basée sur des plages. Stratégie principale : - Utiliser un service central de génération d'ID (comme Twitter Snowflake ou un service de compteur plus simple) qui alloue des blocs d'ID numériques à chaque instance du service de création de liens. Par exemple, chaque instance demande un bloc de 10 000 ID à la fois. - Chaque ID numérique est ensuite encodé en base62 pour produire le code court de 7 caractères. - Cela évite la coordination sur chaque écriture tout en garantissant l'unicité globale. Alternative envisagée : Génération aléatoire avec vérification de collision. Cela fonctionne mais nécessite une lecture avant écriture pour vérifier les collisions, ajoutant de la latence. Avec 7,2 milliards de codes sur 3,5 billions possibles, la probabilité de collision est faible (environ 0,2 %), mais elle nécessite toujours la vérification. L'approche basée sur les plages est plus déterministe. Gestion des alias personnalisés : - Lorsqu'un utilisateur demande un alias personnalisé, le service effectue une écriture conditionnelle (PutItem avec la condition que le short_code n'existe pas déjà) dans la base de données. - Si la condition échoue, l'alias est pris et nous renvoyons une erreur à l'utilisateur. - Les alias personnalisés sont validés : minimum 4 caractères, maximum 30 caractères, alphanumériques plus tirets, vérifiés par rapport à une liste de blocage de mots réservés et de termes offensants. - Les alias personnalisés sont stockés dans la même table que les codes générés, avec le drapeau custom_alias défini sur true. 5. CONCEPTION DE L'API Toutes les API sont RESTful sur HTTPS. a) Créer un lien court : POST /api/v1/links En-têtes : Authorization: Bearer <token> (optionnel pour anonyme, requis pour l'accès aux analyses) Corps de la requête : long_url : requis, l'URL de destination (validée pour le format et la sécurité de base) custom_alias : optionnel, code court souhaité expires_in_days : optionnel, par défaut 1825 (5 ans) Réponse (201 Created) : short_code : "aB3x9Kz" short_url : "https://sho.rt/aB3x9Kz" long_url : "https://example.com/very/long/path" created_at : "2025-01-15T10:30:00Z" expires_at : "2030-01-15T10:30:00Z" Réponses d'erreur : 400 (URL invalide), 409 (alias personnalisé déjà pris), 429 (limité en débit) b) Redirection : GET /{short_code} Réponse : 302 Found avec l'en-tête Location défini sur l'URL longue. Nous utilisons 302 (redirection temporaire) plutôt que 301 (redirection permanente) afin que les navigateurs ne mettent pas en cache la redirection de manière permanente, ce qui nous permet de suivre les clics et potentiellement de mettre à jour la destination. Cependant, pour des raisons de performance, nous pouvons utiliser 301 en périphérie du CDN avec un TTL contrôlé. Réponses d'erreur : 404 (non trouvé ou expiré), 410 (désactivé) c) Obtenir les analyses : GET /api/v1/links/{short_code}/analytics En-têtes : Authorization: Bearer <token> Réponse (200 OK) : short_code : "aB3x9Kz" total_clicks : 154302 daily_clicks : liste d'objets avec date et nombre pour les 30 derniers jours Réponses d'erreur : 401 (non autorisé), 404 (lien non trouvé) d) Supprimer / Désactiver un lien : DELETE /api/v1/links/{short_code} En-têtes : Authorization: Bearer <token> Réponse : 204 No Content 6. STRATÉGIE DE MISE EN CACHE, DE PARTITIONNEMENT ET DE RÉPLICATION Mise en cache : - Couche 1 - Cache Edge CDN : Pour le chemin de redirection, nous pouvons mettre en cache les réponses 302 en périphérie du CDN avec un court TTL (par exemple, 5 minutes). Cela gère extrêmement bien les liens viraux car le CDN absorbe la majorité du trafic. Nous utilisons des en-têtes Cache-Control avec un max-age court. Les workers edge (Cloudflare Workers, Lambda@Edge) peuvent également effectuer la recherche directement à partir d'un magasin KV régional. - Couche 2 - Cluster Redis régional : Chaque région dispose d'un cluster Redis qui met en cache les correspondances short_code vers long_url. TTL du cache de 24 heures. Politique d'éviction LRU. Cela gère la grande majorité des recherches de redirection sans atteindre la base de données. - Couche 3 - Cache local au niveau de l'application : Chaque instance de service de redirection maintient un petit cache LRU en mémoire (par exemple, 100 000 entrées) pour les liens les plus actifs. Taille du cache : Avec 1,2 milliard de redirections par mois et une distribution de Zipf, les 20 % de liens les plus importants représentent probablement 80 % du trafic. La mise en cache des 10 millions de liens actifs dans Redis nécessite environ 10 millions fois 300 octets = 3 Go par région, ce qui est très gérable. Invalidation du cache : Lors de la suppression ou de la mise à jour d'un lien, nous publions un événement d'invalidation dans toutes les régions via la file d'attente de messages. Les entrées du cache ont également des TTL comme filet de sécurité. Partitionnement : - DynamoDB partitionne automatiquement par la clé de hachage short_code. La nature aléatoire des codes générés assure une distribution uniforme. - Pour les alias personnalisés, la distribution est moins prévisible, mais la capacité adaptative de DynamoDB gère les partitions chaudes. - Redis est partitionné à l'aide du hachage cohérent entre les nœuds du cluster. Réplication : - Les tables globales DynamoDB fournissent une réplication multi-régions avec une cohérence éventuelle (généralement inférieure à la seconde). Nous désignons une région comme principale pour les écritures (création de liens) et toutes les régions peuvent servir les lectures. - Alternativement, avec CockroachDB ou Spanner, nous obtenons des lectures multi-régions fortement cohérentes, mais avec un coût de latence plus élevé pour les écritures. - Les clusters Redis sont répliqués au sein de chaque région (primaire-réplique). Le cache inter-régions est rempli indépendamment via la réplication de la base de données et le pré-chauffage du cache local. 7. APPROCHE DE FIABILITÉ Objectif de disponibilité : 99,99 % pour les redirections signifie au plus 4,3 minutes d'indisponibilité par mois. Déploiement multi-régions : - Déployer le service de redirection dans au moins 3 régions géographiquement distribuées (par exemple, US-East, EU-West, AP-Southeast). - Utiliser un routage DNS global (routage basé sur la latence de Route 53 ou anycast) pour diriger les utilisateurs vers la région la plus proche. - Chaque région est capable de servir indépendamment les redirections à partir de son cache local et de sa réplique de base de données. Gestion des pannes : - Si la région de la base de données principale tombe en panne, une autre région est promue. Avec les tables globales DynamoDB, n'importe quelle région peut accepter des écritures, il n'y a donc pas de leader d'écriture unique à basculer. - Si Redis dans une région tombe en panne, le service de redirection se rabat sur la base de données. La base de données peut supporter la charge temporairement et Redis récupère rapidement. - Si le pipeline d'analyse (Kafka) rencontre des problèmes, les événements de clic sont mis en mémoire tampon. La durabilité de Kafka garantit aucune perte de données. La cohérence éventuelle des analyses sous 10 minutes nous donne une marge de manœuvre. - Des disjoncteurs sont implémentés entre les services. Si la base de données est lente, le service de redirection sert à partir du cache et se dégrade gracieusement (renvoie les résultats mis en cache ou une erreur temporaire pour les cache manqués). Vérifications de santé et surveillance : - Chaque instance de service dispose de points de terminaison de vérification de santé. - Les équilibreurs de charge suppriment automatiquement les instances non saines. - Surveillance complète avec des tableaux de bord pour les percentiles de latence (p50, p95, p99), les taux d'erreur, les ratios de succès du cache et le décalage de la file d'attente. - Alertes en cas de violation des SLO. Durabilité des données : - DynamoDB offre une durabilité de 99,999999999 % avec réplication inter-régions. - Sauvegardes régulières comme filet de sécurité supplémentaire. 8. MISE À L'ÉCHELLE POUR LE TRAFIC INTENSIF EN LECTURE ET LES POINTS CHAUDS VIRAUX Le ratio lecture/écriture est d'environ 10:1 (1,2 milliard de lectures contre 120 millions d'écritures par mois), mais lors d'événements viraux, un seul lien peut recevoir des millions de visites par heure. Stratégies : - La mise en cache en périphérie du CDN est la première et la plus efficace défense. La réponse de redirection d'un lien viral est mise en cache dans des centaines d'emplacements périphériques dans le monde. Même un TTL de 5 minutes signifie que l'origine ne voit qu'une requête toutes les 5 minutes par emplacement périphérique. - Le calcul en périphérie (Cloudflare Workers ou Lambda@Edge) peut effectuer la recherche de redirection entièrement en périphérie en lisant à partir d'un magasin KV distribué (comme Cloudflare KV ou DynamoDB DAX), éliminant ainsi le besoin de toucher l'origine. - Mise à l'échelle automatique du cluster Redis : Surveiller la charge du cache et ajouter dynamiquement des répliques de lecture. - Mise à l'échelle automatique du service de redirection : Les services sans état s'adaptent horizontalement en fonction des métriques de CPU et de nombre de requêtes. - Pour les points chauds extrêmes, le cache local au niveau de l'application sur chaque instance de service de redirection garantit que même si Redis est sous pression, les liens les plus actifs sont servis depuis la mémoire. Analyses pendant les événements viraux : - Les événements de clic sont produits vers Kafka, qui gère bien les écritures intermittentes. - Le consommateur d'analyse peut regrouper et agréger avant d'écrire dans le magasin d'analyse, réduisant ainsi l'amplification des écritures. - Nous utilisons des comptages approximatifs si nécessaire (HyperLogLog pour les visiteurs uniques), mais pour les clics totaux, les simples compteurs suffisent. 9. PRÉVENTION DES ABUS Mesures de base (la confiance et la sécurité complètes sont hors champ) : - Limitation de débit sur la création de liens : par IP et par utilisateur authentifié (par exemple, 100 liens par heure pour les anonymes, 1000 pour les authentifiés). - Validation de l'URL : rejeter les URL malformées, vérifier par rapport aux listes de blocage d'URL de phishing/malware connues (par exemple, API Google Safe Browsing). - Validation des alias personnalisés : liste de blocage de mots offensants et réservés. - CAPTCHA pour la création de liens anonymes si les limites de débit sont atteintes. - Possibilité de désactiver les liens signalés comme abusifs (manuellement ou automatiquement). - Journalisation et piste d'audit pour tous les événements de création de liens. 10. ARBITRAGES CLÉS Cohérence vs Latence : - Nous choisissons la cohérence éventuelle pour la correspondance des liens entre les régions. Un lien nouvellement créé peut ne pas être résoluble dans une région distante pendant quelques centaines de millisecondes. Ceci est acceptable car l'utilisateur qui crée le lien est dirigé vers la région la plus proche où l'écriture est immédiatement cohérente, et la réplication inter-régions est rapide. Pour les analyses, nous acceptons explicitement une cohérence éventuelle de 10 minutes. Redirections 302 vs 301 : - 302 (temporaire) nous permet de suivre chaque clic et de modifier les destinations, mais augmente la charge de l'origine. 301 (permanent) est plus efficace mais les navigateurs le mettent en cache indéfiniment. Notre compromis : utiliser 302 depuis l'origine mais permettre la mise en cache en périphérie du CDN avec un court TTL, nous donnant le meilleur des deux mondes. Coût vs Performance : - Le prix à la demande de DynamoDB est plus cher par requête que le prix provisionné, mais gère le trafic intermittent sans planification de capacité. Pour un service à cette échelle, nous utilisons une capacité provisionnée avec mise à l'échelle automatique pour la base et à la demande pour le dépassement. - Le CDN et le calcul en périphérie ajoutent des coûts mais réduisent considérablement les besoins en infrastructure d'origine et améliorent l'expérience utilisateur. Complexité opérationnelle vs Fiabilité : - Le déploiement multi-régions avec les tables globales DynamoDB ajoute de la complexité opérationnelle mais est nécessaire pour l'objectif de disponibilité de 99,99 % et l'exigence de faible latence mondiale. - Kafka ajoute un autre système à exploiter mais fournit le découplage et la durabilité nécessaires pour des analyses fiables. Stockage vs Calcul : - Nous pré-agrégeons les décomptes d'analyses quotidiens plutôt que de les calculer à la volée à partir des événements de clic bruts. Cela échange l'efficacité du stockage contre la performance des requêtes et la simplicité. Unicité des alias personnalisés : - Les alias personnalisés partagent le même espace de noms que les codes générés. Nous réservons l'espace des codes générés (exactement 7 caractères base62) et exigeons que les alias personnalisés aient une longueur différente ou soient vérifiés par rapport à la plage générée. Approche plus simple : tous les codes (générés et personnalisés) vont dans la même table, et l'écriture conditionnelle garantit l'unicité quoi qu'il arrive. 11. RÉSUMÉ DES CHOIX TECHNOLOGIQUES - Équilibrage de charge global : AWS Global Accelerator ou Cloudflare avec DNS anycast - CDN et Edge : CloudFront ou Cloudflare avec workers edge - Calcul : Clusters Kubernetes ou ECS/Fargate dans chaque région pour les services sans état - Base de données principale : Tables globales DynamoDB (correspondances de liens et analyses quotidiennes) - Cache : Clusters Redis ElastiCache dans chaque région - File d'attente de messages : Amazon Kinesis ou Apache Kafka (MSK) pour les événements de clic - Traitement des analyses : Kafka Streams ou Flink pour l'agrégation en temps réel - Génération d'ID : Service d'allocation basé sur des plages soutenu par un petit magasin de coordination (DynamoDB ou ZooKeeper) - Surveillance : CloudWatch, Prometheus, Grafana, PagerDuty pour les alertes Cette conception gère les exigences énoncées avec une séparation claire du chemin d'écriture (création de liens), du chemin de lecture (redirections) et du chemin d'analyse, chacun étant indépendamment évolutif. La stratégie de mise en cache en couches (edge, Redis régional, local) garantit que même le trafic viral extrême est géré avec succès, tandis que l'architecture multi-régions avec les tables globales DynamoDB fournit la durabilité et les garanties de disponibilité nécessaires pour un SLA de 99,99 %.

### 1. Architecture de haut niveau Le système est conçu comme une architecture multi-régions distribuée mondialement pour garantir une faible latence et une haute disponibilité. Chaque région agit comme un point de présence (PoP) autonome. **Composants principaux :** * **Répartiteur de charge global (GLB) :** Utilise un routage basé sur le DNS (par exemple, basé sur la latence, basé sur la géolocalisation) pour diriger les utilisateurs vers la région saine la plus proche. * **CDN (Réseau de diffusion de contenu) :** Se place devant nos serveurs d'applications pour mettre en cache les réponses de redirection (HTTP 301) pour les liens populaires en périphérie, réduisant considérablement la latence et la charge sur notre infrastructure pour le contenu viral. * **Répartiteur de charge régional :** Distribue le trafic au sein d'une région vers les serveurs web sans état. * **Serveurs web (Passerelle API) :** Terminent le TLS et acheminent les requêtes vers le service backend approprié. * **Service de redirection (Chemin de lecture) :** Un microservice sans état hautement optimisé qui gère les requêtes `GET /{short_id}`. Il effectue une recherche (d'abord dans le cache, puis dans la base de données) et émet une redirection. C'est le composant le plus critique et le plus sollicité. * **Service de liens (Chemin d'écriture) :** Un microservice qui gère `POST /api/v1/links` pour la création de nouveaux liens courts. Il coordonne avec le générateur d'ID et écrit dans la base de données. * **Service d'analyse :** Un microservice qui fournit des données d'analyse via `GET /api/v1/links/{short_id}/analytics`. Il lit à partir d'un magasin de données d'analyse dédié. * **Service de génération d'ID :** Un service dédié (par exemple, basé sur Snowflake) qui génère des ID 64 bits uniques globalement et approximativement triables par date, à utiliser pour les liens courts. * **File d'attente de messages (par exemple, Kafka, AWS SQS) :** Dissocie le chemin de redirection critique du traitement non critique des analyses. Le service de redirection publie un événement de clic léger dans la file d'attente pour chaque redirection réussie. * **Processeur d'ingestion d'analyses :** Un service consommateur qui lit à partir de la file d'attente de messages, traite les événements de clic et met à jour le magasin de données d'analyse et les compteurs agrégés. *(Lien vers le diagramme conceptuel)* ### 2. Modèle de données et choix de stockage Nous utiliserons deux magasins de données distincts optimisés pour leurs modèles d'accès spécifiques. **A. Magasin de mappage de liens** * **Choix :** Un magasin clé-valeur NoSQL distribué comme **Amazon DynamoDB** avec des tables globales ou **Apache Cassandra**. * **Justification :** Ce choix est motivé par le besoin d'une évolutivité massive, d'une haute disponibilité et de recherches à faible latence basées sur des clés. Le modèle de lecture principal est une recherche directe par `short_id`, ce qui correspond parfaitement à un modèle clé-valeur. Une configuration multi-régions, multi-maîtres (comme les tables globales DynamoDB) offre des lectures et des écritures à faible latence pour les utilisateurs mondiaux et une récupération après sinistre intégrée. * **Schéma (table `links`) :** * `short_id` (Chaîne, Clé de partition) : Le code unique de 7 caractères ou l'alias personnalisé. * `long_url` (Chaîne) : L'URL de destination. * `created_at` (Horodatage) : Horodatage de création. * `total_clicks` (Nombre) : Un compteur atomique pour le nombre total de clics sur la durée de vie, mis à jour par le processeur d'analyses. **B. Magasin de données d'analyse** * **Choix :** Une base de données à colonnes larges ou à séries chronologiques comme **Apache Cassandra** ou **Amazon Timestream**. * **Justification :** Ce magasin doit gérer un débit d'écriture très élevé d'événements de clic et interroger efficacement les données par plage de temps (par exemple, les 30 derniers jours). Un magasin à colonnes larges nous permet de modéliser cela efficacement. * **Schéma (table `clicks_by_day`) :** * `short_id` (Chaîne, Clé de partition) : L'identifiant du lien. * `event_date` (Chaîne, Clé de clustering, format `YYYY-MM-DD`) : La date des clics. * `daily_count` (Compteur) : Un compteur distribué pour le nombre de clics ce jour-là. Ce modèle pré-agrégé est efficace pour la requête requise ("clics par jour"). Les données brutes des événements pourraient être stockées dans un stockage d'objets moins cher (comme S3) pour une archive à long terme si nécessaire. ### 3. Stratégie de génération d'ID * **ID générés :** Nous avons besoin d'ID courts, uniques et non séquentiels. Une chaîne de 7 caractères utilisant l'encodage Base62 (`[a-zA-Z0-9]`) fournit 62^7 (~3,5 billions) combinaisons uniques, ce qui est plus que suffisant pour les 7,2 milliards de liens attendus sur 5 ans. 1. Le **Service de génération d'ID** produit un entier 64 bits unique globalement (similaire au Snowflake de Twitter), qui combine un horodatage, un ID de région/machine et un numéro de séquence. Cela évite un point de défaillance unique et la contention. 2. Le **Service de liens** demande un ID au générateur. 3. Il encode ensuite l'entier 64 bits en Base62 pour créer la chaîne `short_id`. * **Alias personnalisés :** 1. Lorsqu'un utilisateur soumet un alias personnalisé, le Service de liens effectue une lecture directe sur la table `links` en utilisant l'alias comme clé. 2. Si la clé n'existe pas, il procède à l'écriture de la nouvelle entrée en utilisant une écriture conditionnelle (par exemple, `put if not exists`) pour éviter les conditions de concurrence où deux utilisateurs revendiquent le même alias simultanément. 3. Si la clé existe, il renvoie une erreur 409 Conflict. ### 4. Conception de l'API Le service expose une API RESTful simple. * **Créer un lien court :** `POST /api/v1/links` * **Corps de la requête :** `{"long_url": "https://example.com/very/long/path", "custom_alias": "my-link"}` (custom_alias est facultatif) * **Succès (201 Created) :** `{"short_url": "https://sho.rt/my-link", "long_url": "..."}` * **Erreur (409 Conflict) :** Si l'alias personnalisé est déjà pris. * **Rediriger l'utilisateur :** `GET /{short_id}` * **Exemple :** `GET /aB1x2Yc` * **Succès (301 Moved Permanently) :** `Location: https://example.com/very/long/path` * **Erreur (404 Not Found) :** Si le `short_id` n'existe pas. * **Obtenir les analyses :** `GET /api/v1/links/{short_id}/analytics` * **Succès (200 OK) :** `{"short_id": "aB1x2Yc", "total_clicks": 15023, "daily_clicks": [{"date": "2023-10-27", "clicks": 850}, {"date": "2023-10-26", "clicks": 1200}]}` ### 5. Mise en cache, partitionnement et réplication * **Mise en cache :** Une stratégie de mise en cache à plusieurs niveaux est essentielle pour gérer le trafic à forte lecture et les points chauds viraux. 1. **Mise en cache CDN :** Le CDN met en cache les réponses de redirection `301` en périphérie. C'est la première ligne de défense et elle gère la majeure partie du trafic pour les liens populaires. 2. **Cache en mémoire :** Chaque région dispose d'un cache distribué (par exemple, **Redis Cluster**) qui stocke les mappages `short_id -> long_url`. Le service de redirection suit un modèle de lecture directe : vérifier d'abord Redis, et en cas d'absence, interroger la base de données et remplir le cache avec un TTL (par exemple, 24 heures). 3. **Mise en cache négative :** Mettre en cache les résultats "non trouvés" pendant une courte période (par exemple, 5 minutes) pour éviter les recherches répétées dans la base de données pour les liens invalides ou supprimés. * **Partitionnement :** Les bases de données NoSQL (DynamoDB/Cassandra) partitionnent automatiquement les données en fonction du hachage du `short_id`. Cela distribue la charge de données et d'E/S horizontalement sur le cluster, permettant une mise à l'échelle massive. * **Réplication :** La base de données principale `links` est répliquée dans toutes les régions actives dans une configuration multi-maîtres. Cela garantit qu'un lien créé dans une région est rapidement disponible pour la redirection dans toutes les autres régions, offrant des lectures à faible latence à l'échelle mondiale et une haute durabilité des données. ### 6. Fiabilité et mise à l'échelle * **Fiabilité :** * **Actif-Actif Multi-Régions :** L'ensemble de la pile est déployé dans au moins trois régions géographiquement distinctes. Le GLB effectue des vérifications de santé et redirigera automatiquement le trafic loin de toute région défaillante, permettant au service de survivre à une panne régionale complète. * **Services sans état :** Tous les services (Redirection, Lien, Analyse) sont sans état, ce qui permet de les mettre à l'échelle horizontalement et de les remplacer facilement en cas de défaillance d'une instance. * **Découplage :** La file d'attente de messages garantit qu'un ralentissement ou une défaillance du pipeline d'analyse n'affecte pas la fonctionnalité de redirection critique, orientée utilisateur. * **Mise à l'échelle pour le trafic de lecture :** 1. **CDN :** Le CDN absorbe la majorité des requêtes pour les liens viraux. 2. **Mise à l'échelle horizontale :** Le service de redirection sans état peut être mis à l'échelle en ajoutant plus d'instances derrière le répartiteur de charge régional. 3. **Mise à l'échelle du cache :** Le cache distribué peut être mis à l'échelle en ajoutant plus de nœuds au cluster. 4. **Mise à l'échelle de la base de données :** La base de données NoSQL partitionnée est mise à l'échelle en ajoutant plus de nœuds. ### 7. Compromis clés * **Cohérence vs Disponibilité :** Nous privilégions la Disponibilité par rapport à la Cohérence Forte. L'utilisation d'une base de données multi-maîtres signifie que des conflits d'écriture sont possibles (bien que rares pour ce cas d'utilisation). La cohérence éventuelle est acceptable pour la propagation des liens entre les régions et est requise pour les données d'analyse (délai allant jusqu'à 10 minutes). * **Coût vs Performance :** Une architecture mondiale, multi-régions, actif-actif avec un CDN et plusieurs magasins de données est coûteuse. Cependant, elle est nécessaire pour répondre aux exigences strictes de 99,99 % de disponibilité et de faible latence mondiale. Une conception moins chère à région unique ne suffirait pas. * **Complexité opérationnelle :** L'architecture microservices ajoute de la complexité en termes de déploiement, de surveillance et de maintenance par rapport à un monolithe. Ce compromis est fait pour obtenir une évolutivité indépendante, une isolation des fautes et une résilience pour différentes parties du système.