Concevoir un service de raccourcissement d'URL

## Conception du système : Service de raccourcissement d'URL ### A. Architecture de haut niveau Le système sera composé des composants majeurs suivants : 1. **Équilibreurs de charge (LB) :** Distribuent le trafic entrant (requêtes API pour le raccourcissement et requêtes de redirection) sur plusieurs serveurs API. Nous utiliserons plusieurs couches de LB, en commençant par un LB global (par exemple, AWS Route 53) pour le routage basé sur le DNS, puis des LB régionaux (par exemple, AWS ELB/ALB) pour distribuer le trafic au sein d'une région. 2. **Serveurs API (Serveurs Web) :** Gèrent les requêtes entrantes pour la création d'URL courtes (POST /shorten) et la redirection d'URL courtes (GET /{short_code}). Ces serveurs seront sans état. 3. **Service de raccourcissement d'URL (Logique métier) :** Un microservice responsable de la génération des codes courts, de l'interaction avec la base de données et potentiellement de la mise en cache. 4. **Base de données :** Stocke le mappage entre les codes courts et les URL d'origine. Nous discuterons du choix en détail dans la section C. 5. **Cache :** Stocke les mappages d'URL courtes fréquemment consultés pour réduire la charge de la base de données et la latence des redirections. Redis ou Memcached seront utilisés. 6. **File d'attente de messages (Optionnel mais recommandé pour l'échelle) :** Pour le traitement asynchrone des tâches telles que la mise à jour des analyses ou la gestion des tentatives potentielles, bien que non strictement nécessaire pour la fonctionnalité de base. **Flux des requêtes :** * **Création d'URL (POST /shorten) :** 1. Le client envoie une requête POST avec l'URL d'origine à la passerelle API/l'équilibreur de charge. 2. Le LB transfère la requête à un serveur API disponible. 3. Le serveur API appelle le service de raccourcissement d'URL. 4. Le service de raccourcissement d'URL génère un code court unique (voir section B). 5. Le service stocke le mappage (short_code -> original_url) dans la base de données. 6. Le service peut également écrire le mappage dans le cache. 7. Le serveur API renvoie l'URL raccourcie (par exemple, `https://short.url/{short_code}`) au client. * **Redirection d'URL (GET /{short_code}) :** 1. L'utilisateur saisit une URL raccourcie dans son navigateur. 2. La requête atteint l'équilibreur de charge. 3. Le LB transfère la requête à un serveur API disponible. 4. Le serveur API (ou un service de redirection dédié) vérifie d'abord le cache pour le `short_code`. 5. **Cache trouvé :** Si trouvé, l'URL d'origine est récupérée du cache, et le serveur API émet une réponse HTTP 301 (Redirection permanente) ou 302 (Redirection temporaire) au client avec l'URL d'origine. 6. **Cache manquant :** Si non trouvé dans le cache, le serveur API interroge la base de données pour le `short_code`. 7. La base de données renvoie l'URL d'origine. 8. Le serveur API ajoute le mappage au cache pour les requêtes futures. 9. Le serveur API émet la réponse de redirection HTTP. ### B. Stratégie de génération d'URL courtes Nous avons besoin d'une stratégie qui génère des codes uniques, courts et de préférence d'apparence quelque peu aléatoire. L'objectif principal est l'unicité et l'efficacité. * **Hachage (par exemple, MD5, SHA-1) :** * *Avantages :* Déterministe, peut générer des codes uniques. Peut être tronqué. * *Inconvénients :* Des collisions sont possibles (bien que rares avec un bon hachage et une bonne troncature). Les codes peuvent ne pas être uniformément distribués, entraînant des points chauds. Pas facilement lisibles ou mémorisables par l'homme. * **Basé sur un compteur (par exemple, ID auto-incrémenté) :** * *Avantages :* Garantit l'unicité. Simple à implémenter. * *Inconvénients :* Le compteur centralisé peut devenir un goulot d'étranglement. Les ID séquentiels sont prévisibles et peuvent révéler des modèles d'utilisation. Nécessite un système de compteur distribué pour une haute disponibilité et une mise à l'échelle. * **Pools de clés pré-générés :** * *Avantages :* Distribue la charge de génération. Peut pré-générer un grand pool de codes uniques. * *Inconvénients :* Nécessite la gestion du pool, l'assurance de l'absence de chevauchement et potentiellement la pré-génération d'un nombre massif de clés. * **Encodage Base-62/Base-64 d'un compteur :** * *Avantages :* Génère des codes courts et uniques en encodant un compteur monotone croissant (par exemple, un entier de 64 bits) dans un alphabet base-62 (0-9, a-z, A-Z) ou base-64. C'est efficace et produit des chaînes relativement courtes. Garantit l'unicité si le compteur est géré correctement. * *Inconvénients :* Nécessite un service de compteur distribué pour éviter les goulots d'étranglement et garantir l'unicité entre plusieurs serveurs API. **Stratégie choisie : Encodage Base-62 d'un compteur distribué** Cette approche offre le meilleur équilibre entre unicité, brièveté et évolutivité. Nous utiliserons un service de génération d'ID distribué (comme Snowflake de Twitter ou Apache ZooKeeper) pour générer des ID uniques et séquentiels de 64 bits. Chaque ID sera ensuite encodé en une chaîne base-62. Cela fournit des codes courts et uniques. La nature séquentielle des ID peut être gérée pour éviter les modèles prévisibles en utilisant une composante aléatoire dans la génération d'ID ou en mélangeant le mappage ultérieurement. ### C. Stockage des données **Technologie de base de données :** Une base de données NoSQL comme **Cassandra** ou **ScyllaDB** (une base de données compatible Cassandra haute performance) est un candidat solide en raison de sa nature distribuée, de sa haute disponibilité et de ses excellentes performances d'écriture, cruciales pour la création d'URL. Alternativement, une base de données relationnelle sharding (comme PostgreSQL avec Citus ou MySQL avec Vitess) pourrait fonctionner, mais NoSQL simplifie souvent la mise à l'échelle pour ce type de recherche clé-valeur. Supposons **Cassandra** pour sa mise à l'échelle linéaire et sa tolérance aux pannes. **Schéma :** Nous utiliserons un schéma simple dans un keyspace optimisé pour les lectures : ```cql CREATE TABLE url_mappings ( short_code text PRIMARY KEY, original_url text, created_at timestamp ); ``` * `short_code` : Le code court unique généré (par exemple, `aBcDeF`). C'est la clé primaire. * `original_url` : L'URL longue vers laquelle rediriger. * `created_at` : Horodatage de la création de l'URL raccourcie. **Estimation des besoins de stockage (sur 5 ans) :** * **Nouvelles URL par mois :** 100 millions * **Total d'URL sur 5 ans :** 100 millions/mois * 12 mois/an * 5 ans = 6 milliards d'URL * **Longueur moyenne du code court :** L'encodage Base-62 d'un entier de 64 bits donne environ 11 caractères. Supposons 15 octets pour le `short_code` (y compris la surcharge). * **Longueur moyenne de l'URL d'origine :** Supposons 2000 octets (les URL peuvent être très longues). * **Surcharge :** Supposons une surcharge de 10 % pour le stockage de la base de données (réplication, index, etc.). **Stockage total :** (6 milliards d'URL) * (15 octets/short_code + 2000 octets/original_url) * 1.10 (surcharge) = 6 * 10^9 * 2015 octets * 1.10 ≈ 13.3 * 10^12 octets ≈ 13.3 Téraoctets (To) C'est une quantité gérable pour une base de données NoSQL distribuée comme Cassandra, qui peut évoluer horizontalement en ajoutant plus de nœuds. **Pourquoi Cassandra ?** * **Évolutivité :** Évolue linéairement en ajoutant des nœuds, gérant une quantité massive de données et de trafic. * **Disponibilité :** Conçu pour une haute disponibilité sans point de défaillance unique. Les données sont répliquées sur plusieurs nœuds et centres de données. * **Performances d'écriture :** Excellent débit d'écriture, crucial pour la partie création d'URL. * **Performances de lecture :** Peut être optimisé pour des recherches clé-valeur rapides, ce qui est ce que la redirection exige. ### D. Stratégie de mise à l'échelle **1. Stratégie de mise en cache :** * **Cache de niveau 1 (Cache distribué) :** Utiliser un cluster Redis ou Memcached. Stocker les mappages `short_code -> original_url`. Cela servira la grande majorité des requêtes de lecture (99 % du trafic, compte tenu du ratio lecture/écriture de 100:1). * **Invalidation/Expiration du cache :** Pour simplifier et compte tenu de la durée de vie de 5 ans, nous pouvons utiliser un Temps de vie (TTL) légèrement supérieur au modèle d'accès attendu, ou simplement nous fier au fait qu'une fois qu'une URL courte est créée, son mappage change rarement. Une stratégie courante consiste à mettre en cache indéfiniment jusqu'à ce que l'application redémarre ou qu'une invalidation manuelle soit déclenchée (bien que cela soit moins courant pour les raccourcisseurs d'URL). * **Remplissage du cache :** Lorsqu'une requête de redirection manque le cache, l'URL d'origine est récupérée de la base de données, puis écrite dans le cache avant de renvoyer la redirection. **2. Partitionnement/Sharding de la base de données :** * **Cassandra :** Cassandra gère le partitionnement automatiquement en fonction de la clé primaire (`short_code`). Les données sont distribuées sur les nœuds à l'aide d'un algorithme de hachage cohérent. Cela sharde intrinsèquement les données. * **Base de données relationnelle (si choisie) :** Sharder la base de données en fonction du `short_code` (par exemple, en utilisant un hachage du `short_code` pour déterminer le shard). Cela distribue la charge et les données sur plusieurs instances de base de données. **3. Gestion des clés chaudes (URL virales) :** * **Mise en cache :** La principale défense contre les clés chaudes est une mise en cache agressive. Une URL virale sera fortement mise en cache dans Redis/Memcached, ce qui signifie que les requêtes ultérieures seront servies directement depuis la mémoire, en contournant la base de données. * **Répliques de lecture de la base de données (si utilisation de RDBMS) :** Si la base de données devient un goulot d'étranglement même avec la mise en cache, des répliques de lecture peuvent être utilisées, bien que la nature distribuée de Cassandra gère déjà cela efficacement. * **Réseau de diffusion de contenu (CDN) :** Pour un trafic extrêmement élevé, les réponses de redirection elles-mêmes pourraient potentiellement être mises en cache en périphérie à l'aide d'un CDN, bien que cela ajoute de la complexité et puisse ne pas convenir à tous les types de redirection (par exemple, 302). Cependant, les serveurs API eux-mêmes pourraient être placés derrière un CDN pour un accès mondial plus rapide. * **Chemin de lecture dédié :** Dans des cas extrêmes, une base de données distincte optimisée pour la lecture ou une couche de cache pourrait être envisagée, mais le cache principal devrait gérer la plupart des scénarios de clés chaudes. ### E. Fiabilité et tolérance aux pannes **1. Haute disponibilité (99,9 % de disponibilité) :** * **Redondance :** Déployer plusieurs instances de chaque composant (serveurs API, nœuds de cache, nœuds de base de données) dans plusieurs zones de disponibilité (AZ) ou même régions. * **Équilibreurs de charge :** Les LB achemineront automatiquement le trafic loin des instances non saines. * **Serveurs API sans état :** Les serveurs API sont sans état, donc n'importe quel serveur peut gérer n'importe quelle requête. Si l'un tombe en panne, les autres prennent le relais de manière transparente. * **Réplication de base de données :** Cassandra fournit une réplication de données intégrée. Nous configurerons un facteur de réplication (par exemple, 3) sur différents nœuds et racks/AZ. Si un nœud tombe en panne, les répliques sur d'autres nœuds servent les données. * **Réplication/Clustering de cache :** Redis Sentinel ou Redis Cluster peut fournir une haute disponibilité pour le cache. **2. Gestion des pannes de composants :** * **Panne de serveur API :** Les LB détectent la panne et arrêtent d'envoyer du trafic à l'instance non saine. D'autres instances continuent de servir les requêtes. * **Panne de nœud de cache :** Si Redis Cluster ou Sentinel est utilisé, le système promeut automatiquement une réplique ou reconfigure le cluster. Si un seul nœud tombe en panne, certaines données mises en cache peuvent être temporairement indisponibles, mais le système se rabattra sur la base de données. * **Panne de nœud de base de données :** Cassandra gère automatiquement les pannes de nœuds. Les données sont disponibles à partir des répliques sur d'autres nœuds. Si une AZ entière tombe en panne, les données sont toujours disponibles à partir des nœuds dans d'autres AZ (si déploiement multi-AZ). **3. Réplication et basculement des données :** * **Base de données :** La stratégie de réplication de Cassandra garantit la durabilité et la disponibilité des données. Nous utiliserons un facteur de réplication de 3, avec des répliques réparties sur différents emplacements physiques (racks/AZ). Si un nœud tombe en panne, les lectures et les écritures peuvent toujours être servies par d'autres répliques. * **Cache :** Redis Sentinel ou Cluster fournit un basculement automatique pour les nœuds de cache. * **Niveau application :** Implémenter des mécanismes de nouvelle tentative pour les problèmes réseau transitoires lors de la communication entre services. ### F. Compromis clés 1. **Cohérence vs Disponibilité (Théorème CAP) :** * **Choix :** Nous privilégions la **Disponibilité** et la **Tolérance aux partitions** par rapport à une forte Cohérence pour le service de redirection. Pour la création d'URL, nous avons besoin d'une forte cohérence pour garantir des codes courts uniques. Pour la redirection, si une réplique de base de données est temporairement indisponible, nous préférons servir une entrée obsolète du cache ou renvoyer une erreur plutôt que de bloquer les requêtes. * **Justification :** La fonction principale d'un raccourcisseur d'URL est de rediriger les utilisateurs rapidement et de manière fiable. Des entrées de cache occasionnellement obsolètes ou une indisponibilité temporaire d'un mappage d'URL courte spécifique (ce qui serait rare avec une réplication appropriée) sont plus acceptables que des pannes de service généralisées. Pour la création d'URL, un générateur d'ID distribué avec des garanties de forte cohérence est utilisé pour assurer l'unicité. 2. **Latence vs Coût/Complexité (Stratégie de mise en cache) :** * **Choix :** Nous avons choisi une stratégie de mise en cache agressive et multi-couches (cache en mémoire comme Redis/Memcached) pour atteindre l'exigence de latence inférieure à 50 ms pour les redirections. * **Justification :** Le ratio lecture/écriture de 100:1 et l'exigence de latence stricte (99,9 % de disponibilité, <50 ms de latence au 95e percentile) rendent la mise en cache essentielle. Servir la plupart des requêtes directement depuis la RAM réduit considérablement la charge de la base de données et les temps de réponse. Bien que la mise en cache ajoute de la complexité (invalidation du cache, problèmes de cohérence, coût d'infrastructure supplémentaire), c'est un compromis nécessaire pour répondre aux objectifs de performance et de disponibilité. Sans cela, la base de données serait submergée par le trafic de lecture, entraînant une latence plus élevée et des pannes potentielles.

A) Architecture de haut niveau Composants 1) Périphérie (Edge) - DNS + CDN/Anycast périphérique (facultatif mais fortement recommandé pour <50 ms p95 globalement) - WAF + protection DDoS - Répartiteurs de charge globaux (GSLB) acheminant vers la région la plus proche 2) Pile régionale (au moins 2 régions, actif-actif) - Répartiteur de charge L7 (ALB/Envoy) - Service API sans état (raccourcisseur d'URL) - API de création (chemin d'écriture) - API de redirection (chemin de lecture) - Couche de cache - Cache L1 en mémoire (minuscule, par instance, clés très chaudes) - Cache distribué L2 (cluster Redis/Memcached) - Stockage persistant - Magasin KV principal (mapping short_code -> long_url de style DynamoDB/Cassandra/ScyllaDB) - Magasin relationnel facultatif (Postgres/MySQL) pour l'analytique, les comptes utilisateur, les alias personnalisés (pas dans le chemin de redirection critique) - Pipeline asynchrone (non critique) - Kafka/Kinesis/PubSub pour les événements de clic, les journaux, les signaux d'abus - Processeurs de flux / puits OLAP (ClickHouse/BigQuery/S3) Flux de requête : Création d'URL (écriture) 1) Le client appelle POST /api/shorten avec long_url (+ alias personnalisé facultatif, politique TTL, authentification utilisateur). 2) La requête atteint le GSLB -> répartiteur de charge régional -> serveur API. 3) L'API valide l'URL (format, listes autorisées/refusées, navigation sécurisée), la normalise, applique des limites de débit. 4) Le service de génération de code court alloue un code unique (détails dans la section B). 5) L'API écrit le mapping dans le magasin KV (short_code comme clé de partition). - L'écriture inclut created_at, expire_at (>=5 ans), long_url, owner_id, drapeaux. - Utiliser une écriture de quorum (ou une écriture fortement cohérente selon le magasin). 6) L'API remplit le cache L2 avec short_code -> long_url (write-through) et renvoie l'URL courte. 7) Émettre des événements asynchrones (créé, utilisateur, score de spam) vers le flux ; non requis pour la réponse réussie. Flux de requête : Redirection d'URL (lecture) 1) Le navigateur demande GET /{code}. 2) Le périphérique achemine vers la région la plus proche ; le CDN facultatif peut mettre en cache les réponses 301/302 si la politique le permet. 3) Le serveur API analyse le code. 4) Ordre de recherche : a) Cache L1 en mémoire b) Cache distribué L2 Redis/Memcached c) Magasin KV (en cas de cache manqué) 5) Si trouvé et non expiré/bloqué : renvoyer une redirection HTTP 301/302 avec Location: long_url. - Remplissage du cache en cas de manqué (défini dans L2 ; éventuellement L1). 6) Émettre un événement de clic de manière asynchrone (fire-and-forget). 7) Si non trouvé : 404 (éventuellement retour à la région d'origine si utilisation de l'isolation régionale). Cibles de latence - Le succès du cache L2 devrait dominer (sub-milliseconde à quelques ms dans la région). Avec le routage périphérique + taux de succès de cache élevé, <50 ms p95 est réalisable. B) Stratégie de génération d'URL courte Exigences - 100 millions de raccourcissements par mois ~ 3,3 millions/jour ~ ~38,6 écritures/sec en moyenne (pics plus élevés). - Doit générer des codes uniques, courts, sûrs pour les URL, avec un faible risque de collision et sans goulot d'étranglement de coordination. Options 1) Hash(long_url) - Avantages : déterministe ; déduplication possible. - Inconvénients : les collisions nécessitent une gestion ; révèle des modèles ; difficile de prendre en charge plusieurs URL longues identiques pour différents utilisateurs ; la modification de la normalisation affecte la stabilité. 2) Compteur central (auto-incrément) + encodage base62 - Avantages : compact ; pas de collisions ; simple. - Inconvénients : seul goulot d'étranglement logique sauf s'il est fragmenté ; les codes séquentiels sont devinables (sécurité/abus). 3) ID distribué (type Snowflake : temps + worker + séquence) puis base62 - Avantages : pas de coordinateur central ; évolutif ; unique ; taille limitée. - Inconvénients : codes légèrement plus longs ; l'ordre basé sur le temps divulgue certaines informations. 4) Pool de clés pré-générées - Avantages : allocation la plus rapide ; découple la création de la génération d'ID. - Inconvénients : nécessite la gestion du pool, du stockage et l'évitement de la réutilisation ; complexité opérationnelle. Approche choisie - Utiliser un ID unique de 64 bits de style Snowflake généré par chaque nœud API (ou service d'ID dédié) et l'encoder en base62/base64url. - 64 bits en base62 donnent jusqu'à 11 caractères dans le pire des cas ; généralement 10 à 11 caractères, ce qui est acceptable. - Si des codes plus courts sont requis, utiliser 56 à 60 bits (toujours suffisants) avec une époque/fenêtre temporelle et des bits de travail soigneusement choisis. - Pour réduire la prévisibilité, appliquer éventuellement une permutation réversible (par exemple, réseau de Feistel) à l'ID de 64 bits avant l'encodage base62 ; conserve l'unicité mais rend les codes non séquentiels. Pourquoi ce choix - Élimine le goulot d'étranglement du compteur unique. - Pas besoin de gérer les collisions. - Fonctionne bien avec l'actif-actif multi-régions. - La prévisibilité est atténuée par la permutation. Alias personnalisés - Si l'utilisateur demande un code personnalisé, vérifier la disponibilité avec une écriture conditionnelle (put-if-absent) dans le magasin KV ; en cas de conflit, rejeter. C) Stockage de données Choix de la base de données - Magasin principal : une base de données KV hautement disponible et évolutive horizontalement (DynamoDB ou Cassandra/ScyllaDB). - Raisonnement : - Le modèle d'accès est la lecture par clé basée sur short_code. - Fortement orienté lecture à QPS élevé ; les magasins KV excellent dans les recherches ponctuelles à faible latence. - Réplication intégrée, partitionnement et maturité opérationnelle. Schéma (une seule table) Table : url_mapping - Clé de partition : short_code (chaîne) - Attributs : - long_url (chaîne) - created_at (horodatage) - expire_at (horodatage, doit être >= created_at + 5 ans ; peut être nul pour « jamais », mais l'exigence dit au moins 5 ans) - owner_id (chaîne, facultatif) - status (actif/désactivé/malveillant) - meta (facultatif : titre, campagne, etc.) Index (facultatif) - GSI/index secondaire sur owner_id + created_at pour lister les liens utilisateur (pas sur le chemin de redirection). Estimation du stockage (5 ans) - Nouvelles URL : 100 millions/mois * 12 * 5 = 6 milliards de mappings. - Estimation de la taille par enregistrement : - short_code : 10–11 octets (stocké comme ~16 octets avec surcharge) - long_url : suppose une moyenne de 100 octets (pourrait être 50–200 ; utiliser 120 avec surcharge) - horodatages/statut/owner_id : ~40 octets en moyenne (owner_id facultatif) - Surcharge de la base de données (clés, métadonnées de réplication, compression) : varie ; suppose ~100 octets de surcharge - Total logique par élément ~250 octets (conservateur) - Stockage logique brut : 6e9 * 250B = 1,5 To. - Avec un facteur de réplication de 3 (courant dans Cassandra/Scylla) : ~4,5 To. - Ajouter des index + marge : prévoir ~6–10 To dans tout le cluster sur 5 ans. Notes - Les URL longues peuvent être compressées (dictionnaire/deflate) au niveau de l'application pour réduire la taille ; mais seulement si cela n'ajoute pas de latence. De nombreux magasins KV compressent également les SSTables. D) Stratégie de mise à l'échelle Estimation du trafic - Écritures : ~38,6/s en moyenne ; supposer un pic de 10x => ~400/s. - Lectures : 100:1 => ~3 860 lectures/s en moyenne ; pic potentiellement beaucoup plus élevé (par exemple, 50k–200k/s selon les pics d'utilisation). Mise à l'échelle des lectures 1) Mise en cache - Cache L1 en mémoire : minuscule (par exemple, 10k–100k entrées) avec un TTL court (30–120 s) pour absorber les micro-points chauds et réduire le QPS de Redis. - Redis/Memcached L2 : - Valeur du cache : long_url + statut + expire_at. - Stratégie TTL : - Si les liens sont immuables (courant), définir un TTL long (heures à jours). - Respecter toujours expire_at en définissant TTL = min(configured_max_ttl, expire_at - now). - Utiliser le cache-aside avec mise en cache négative : - Mettre en cache « non trouvé » pour un TTL court (par exemple, 30–60 s) pour réduire les accès à la base de données des scanners. - Viser un taux de succès de cache > 95–99 % pour les redirections. 2) Mise en cache CDN (facultatif mais puissant) - Pour les redirections 301 stables, le CDN peut mettre en cache la réponse de redirection pour les codes populaires. - Doit tenir compte de la capacité à désactiver rapidement les liens ; atténuer par : - TTL CDN court (par exemple, 60–300 s) + purge lors de la désactivation - Ou conserver la logique de redirection à l'origine mais mettre en cache le mapping à la périphérie KV (avancé). Partitionnement/fragmentation de la base de données - Partitionner par short_code (hachage cohérent / anneau de jetons). - Distribution uniforme attendue car les codes sont pseudo-aléatoires (après permutation). - Ajouter des nœuds pour une mise à l'échelle linéaire. Gestion des clés chaudes (URL virales) - Approche multi-couches : 1) Le cache périphérique/CDN met en cache la réponse de redirection pour les clés les plus chaudes avec un TTL court. 2) Les caches L1 + L2 réduisent la charge de la base de données d'origine. 3) Mise à l'échelle du cluster Redis : fragmenter par clé ; activer le hachage côté client. 4) Coalescence des requêtes / vol unique en cas de cache manqué : si de nombreuses requêtes manquent simultanément pour la même clé, une requête remplit le cache pendant que les autres attendent brièvement. 5) Pour les cas extrêmes, autoriser la « réplication de clé chaude » dans le cache (stocker la même clé dans plusieurs fragments) ou utiliser une couche « cache chaud » dédiée. Mise à l'échelle des écritures - Les écritures sont modestes ; assurer des écritures conditionnelles pour l'unicité et l'idempotence. - Utiliser la limitation de débit et la prévention des abus pour éviter l'amplification des écritures par les bots. E) Fiabilité et tolérance aux pannes (disponibilité de 99,9 %) Multi-régions - Actif-actif dans au moins 2 régions. - Les vérifications de santé GSLB redirigent le trafic loin de la région non saine. Services sans état - Les serveurs API sont sans état ; mise à l'échelle horizontale ; déploiement dans plusieurs zones AZ. Couche de cache - Redis/Memcached déployé comme un cluster fragmenté avec des répliques par fragment (ou Redis Cluster avec répliques). - Si le cache tombe en panne : le système se rabat sur la base de données ; latence accrue mais toujours fonctionnel. - Protéger la base de données avec des disjoncteurs et une limitation de débit adaptative si une panne de cache provoque un « thundering herd ». Réplication et basculement de la base de données - Option DynamoDB : - Utiliser des tables globales pour la réplication actif-actif multi-régions. - Configurer la capacité à la demande ou provisionnée avec mise à l'échelle automatique. - Option Cassandra/Scylla : - Réplication multi-AZ dans la région (RF=3). - Réplication multi-régions via NetworkTopologyStrategy ; ajuster la cohérence (par exemple, LOCAL_QUORUM pour les lectures/écritures) pour maintenir une faible latence. - Modes de défaillance : - Défaillance d'un seul nœud : les lectures/écritures des répliques continuent. - Défaillance d'AZ : les AZ restantes servent le trafic (RF entre les AZ). - Défaillance de région : GSLB bascule vers la région saine ; données disponibles via le magasin répliqué. Durabilité des données - Sauvegardes/instantanés réguliers vers le stockage objet (S3/GCS) + récupération ponctuelle. - Exercices de reprise après sinistre et tests de restauration. Sécurité du déploiement - Déploiements progressifs + versions canary. - Indicateurs de fonctionnalité. - Annulation automatique en cas de dépassement du budget d'erreur. Contrôles opérationnels - SLI : latence p95 de redirection, taux de succès du cache, p95 de la base de données, taux d'erreur, retard de réplication. - SLO : disponibilité de 99,9 % ; conception pour une dégradation gracieuse (par exemple, désactiver temporairement les écritures analytiques). F) Compromis clés 1) Courte longueur du code vs génération distribuée - Compromis : un compteur centralisé peut produire des codes très courts (souvent 6 à 8 caractères au début), mais ajoute de la coordination et est plus difficile en multi-régions. - Choix : IDs distribués de style Snowflake + base62 (10–11 caractères) pour assurer l'évolutivité, l'unicité et la compatibilité multi-régions tout en répondant aux exigences de latence/disponibilité. 2) Cohérence forte vs faible latence/haute disponibilité - Compromis : les lectures globales fortement cohérentes augmentent la latence et réduisent la disponibilité pendant les partitions. - Choix : utiliser la cohérence locale/régionale pour les recherches de redirection (rapide) avec réplication multi-régions. Pour les opérations de création, assurer l'unicité avec des écritures conditionnelles et accepter la propagation inter-régionale éventuelle ; les redirections restent correctes car le mapping faisant autorité existe dans au moins une région et est rapidement répliqué. 3) Mise en cache agressive vs réponse rapide de désactivation/abus - Compromis : les TTL de cache longs améliorent la latence et réduisent la charge de la base de données, mais rendent plus difficile la désactivation immédiate des liens malveillants. - Choix : TTL modérés + mécanismes de purge, ainsi que des vérifications de statut dans la valeur mise en cache et un TTL court pour le CDN ; permettre un « interrupteur d'urgence » en mettant en cache le statut désactivé avec une priorité élevée. Résumé - Utiliser le routage périphérique + une mise en cache intensive pour maintenir les redirections en dessous de 50 ms p95. - Utiliser la génération d'ID unique distribuée (Snowflake + permutation) pour une génération de code évolutive. - Stocker les mappings dans un magasin KV répliqué avec fragmentation par short_code et basculement multi-régions. - Maintenir une disponibilité de 99,9 % grâce à multi-AZ + multi-régions, des services sans état, un stockage répliqué et des chemins de dégradation gracieuse.