Concevoir un service de raccourcissement d'URL à grande échelle

### A. Architecture de haut niveau Le système est conçu comme un ensemble de microservices distribués et sans état, déployés dans plusieurs régions géographiques pour garantir une haute disponibilité et une faible latence. Les principaux composants sont : 1. **Répartiteur de charge global (GLB)** : Distribue le trafic utilisateur vers la région la plus proche et la plus saine à l'aide d'un routage basé sur le DNS (par exemple, AWS Route 53, Google Cloud Load Balancing). 2. **Répartiteurs de charge régionaux (RLB)** : Distribuent le trafic au sein d'une région unique vers le parc de serveurs web. 3. **Passerelle API / Serveurs Web** : Une couche de serveurs sans état qui termine le TLS et gère les requêtes HTTP entrantes pour les écritures (raccourcissement) et les lectures (redirection). 4. **Service de redirection (Chemin de lecture)** : Un service hautement optimisé responsable de la recherche de codes courts et de l'émission de redirections HTTP 301/302. Il interagit principalement avec la couche de mise en cache. 5. **Service de raccourcissement d'URL (Chemin d'écriture)** : Un service qui gère la création de nouvelles URL courtes. Il coordonne avec le service de génération de clés et la base de données principale. 6. **Cache distribué** : Un cache en mémoire (par exemple, Redis Cluster) dans chaque région qui stocke les mappages d'URL fréquemment consultés pour répondre à l'exigence stricte de faible latence pour les redirections. 7. **Base de données principale** : Une base de données NoSQL distribuée (par exemple, Apache Cassandra, Amazon DynamoDB) qui sert de source de vérité persistante pour tous les mappages d'URL, répliquée dans toutes les régions. 8. **Service de génération de clés (KGS)** : Un service dédié et hautement disponible qui pré-génère des lots de codes courts uniques de 7 caractères pour éliminer les collisions et la latence au moment de l'écriture. 9. **Pipeline d'analyse** : Un pipeline de données asynchrone commençant par une file d'attente de messages (par exemple, Apache Kafka) pour ingérer les données de clics sans impacter les performances du service de redirection. Ces données sont ensuite traitées et stockées dans une base de données d'analyse distincte. ### B. Stratégie de génération d'URL **Approche** : Nous utiliserons un service de génération de clés dédié (KGS) pour pré-générer des clés uniques. **Mécanisme** : 1. Le KGS maintient un compteur de manière distribuée et tolérante aux pannes (par exemple, en utilisant ZooKeeper ou un compteur atomique dans une base de données comme Redis). 2. Il génère de grands identifiants numériques séquentiels. Pour garantir une haute disponibilité, plusieurs instances KGS peuvent être exécutées, chacune responsable d'une plage d'identifiants différente (par exemple, Serveur 1 gère de 1 à 1 000 000, Serveur 2 gère de 1 000 001 à 2 000 000). 3. Chaque identifiant numérique est ensuite converti en une chaîne base-62 ([a-z, A-Z, 0-9]) pour produire le code court de 7 caractères. Un espace de 62^7 fournit environ 3,5 billions de codes uniques, ce qui est plus que suffisant. 4. Le KGS génère ces codes par lots et les place dans une file d'attente (par exemple, une liste Redis) que le service de raccourcissement d'URL consommera. **Justification** : Cette approche évite la nécessité de vérifier les collisions dans la base de données principale lors d'une opération d'écriture, ce qui serait lent et un point de contention. Elle rend le chemin d'écriture extrêmement rapide et prévisible, car le service de raccourcissement doit simplement récupérer une clé garantie unique du KGS. ### C. Modèle de données et stockage **Stockage principal (Mappages d'URL)** : * **Technologie** : Apache Cassandra ou Amazon DynamoDB. * **Pourquoi** : Ces bases de données NoSQL offrent une excellente évolutivité horizontale, une réplication native multi-régions, une haute disponibilité et des recherches clé-valeur à faible latence, ce qui correspond parfaitement à nos exigences d'échelle et de tolérance aux pannes. * **Schéma** : * Nom de la table : `url_mappings` * Clé de partition : `short_code` (chaîne) * Colonnes : * `long_url` (chaîne) * `user_id` (chaîne, pour la propriété) * `created_at` (horodatage) **Stockage Cache** : * **Technologie** : Redis Cluster. * **Pourquoi** : Redis fournit un accès aux données en mémoire à très faible latence (inférieure à la milliseconde), ce qui est essentiel pour répondre à l'exigence de redirection <10 ms. Il peut être mis en cluster pour l'évolutivité et la haute disponibilité. **Stockage d'analyse** : * **Technologie** : Une base de données orientée colonnes comme Apache Druid, ClickHouse, ou un entrepôt de données cloud comme Google BigQuery. * **Pourquoi** : Ces systèmes sont optimisés pour des agrégations rapides et des requêtes analytiques sur des ensembles de données massifs, ce qui est idéal pour alimenter le tableau de bord d'analyse. ### D. Optimisation du chemin de lecture Le chemin de lecture est fortement optimisé pour la latence à l'aide d'une stratégie de mise en cache à plusieurs niveaux pour gérer les 40 000 QPS de pointe. 1. **Cache CDN/Edge** : Pour les URL extrêmement populaires, un CDN peut mettre en cache la réponse de redirection 301/302 aux emplacements périphériques, servant les utilisateurs depuis le point de présence le plus proche sans toucher notre infrastructure principale. 2. **Cache distribué en mémoire (Redis)** : C'est le principal moteur de la faible latence. Le service de redirection interroge d'abord le cluster Redis régional. Un succès du cache entraîne une redirection immédiate. * **Estimation de la taille du cache** : Pour mettre en cache 20 % de 5 ans d'URL (100M/mois * 12 * 5 * 0,2 = 1,2 milliard d'URL). À environ 600 octets par entrée (code court, URL longue, surcharge), cela nécessite environ 720 Go de RAM par région, ce qui est réalisable pour un cluster Redis. 3. **Recherche dans la base de données** : En cas de manque dans le cache, le service interroge la base de données principale Cassandra/DynamoDB. Le résultat est ensuite réécrit dans le cache Redis avec une durée de vie (TTL) pour garantir que le cache reste rempli des éléments fréquemment consultés. Cette architecture garantit que la grande majorité des requêtes sont servies à partir de la mémoire, atteignant facilement l'objectif de latence p99 <10 ms. ### E. Chemin d'écriture Le chemin d'écriture est conçu pour la fiabilité et le débit (~400 écritures/sec de pointe). 1. Un utilisateur envoie une requête POST avec l'URL longue à la passerelle API. 2. La requête est acheminée vers une instance du service de raccourcissement d'URL. 3. Le service valide l'URL longue. 4. Il demande un code court unique au service de génération de clés (KGS). 5. Le service écrit le nouveau mappage (`short_code`, `long_url`) dans la base de données principale (Cassandra/DynamoDB) avec un niveau de cohérence élevé pour la région locale. 6. La base de données réplique de manière asynchrone cette écriture vers d'autres régions. 7. Après une écriture réussie dans la base de données, le service renvoie la nouvelle URL courte à l'utilisateur. ### F. Stratégie de mise à l'échelle Le système est conçu pour évoluer horizontalement à chaque niveau : * **Services sans état** : La passerelle API, le service de redirection et le service de raccourcissement sont sans état. Nous pouvons les faire évoluer en ajoutant plus de machines virtuelles ou de conteneurs derrière les répartiteurs de charge. * **Base de données** : Cassandra et DynamoDB sont conçus pour évoluer horizontalement en ajoutant plus de nœuds au cluster. Les données et la charge sont automatiquement rééquilibrées. * **Cache** : Redis Cluster peut être mis à l'échelle en ajoutant plus de nœuds et en re-partitionnant l'espace de clés. * **Pipeline d'analyse** : Kafka évolue en ajoutant plus de courtiers et de partitions. Les services consommateurs qui traitent les données peuvent également être mis à l'échelle horizontalement. ### G. Fiabilité et tolérance aux pannes La haute disponibilité est assurée par la redondance dans plusieurs régions géographiques (par exemple, US-East, US-West, EU-West). * **Déploiement multi-régions** : L'ensemble de la pile est déployé dans au moins deux régions indépendantes. * **Basculement global** : Le répartiteur de charge global surveille en permanence la santé de chaque région. Si une région entière devient indisponible, le GLB redirige automatiquement tout le trafic vers les régions saines. * **Réplication des données** : La base de données principale (Cassandra/DynamoDB) est configurée pour la réplication multi-régions. Cela garantit que si une base de données régionale est perdue, les données sont préservées dans d'autres régions. Les écritures peuvent continuer à être servies dans les régions actives restantes. * **Aucun point de défaillance unique** : Chaque composant, des répartiteurs de charge au KGS et aux bases de données, est déployé dans une configuration groupée et tolérante aux pannes. ### H. Pipeline d'analyse Le pipeline d'analyse est conçu pour être complètement découplé du chemin de redirection critique afin d'éviter toute dégradation des performances. 1. **Ingestion des données** : Après avoir servi avec succès une redirection, le service de redirection publie un message dans un sujet Kafka. Ce message contient des données d'événement telles que `short_code`, `timestamp`, `adresse IP`, `User-Agent` et `Referrer`. Il s'agit d'une opération asynchrone et non bloquante. 2. **Traitement des données** : Un parc distinct de travailleurs de traitement de flux (par exemple, utilisant Spark Streaming, Flink ou des consommateurs personnalisés) lit les messages du sujet Kafka par lots. 3. **Enrichissement et agrégation des données** : Ces travailleurs enrichissent les données (par exemple, conversion de l'IP en géolocalisation) et effectuent des agrégations en temps réel (par exemple, incrémentation des comptes de clics par heure, par pays). 4. **Stockage des données** : Les données traitées et agrégées sont chargées dans la base de données d'analyse (ClickHouse/Druid), qui est optimisée pour alimenter efficacement les requêtes du tableau de bord destinées aux utilisateurs. Cette architecture asynchrone garantit qu'une augmentation massive du trafic ou une défaillance du pipeline d'analyse n'aura aucun impact sur la vitesse et la disponibilité des redirections d'URL. ### I. Compromis clés 1. **Cohérence éventuelle vs. Cohérence forte** : Nous avons choisi un modèle de réplication de données à cohérence éventuelle entre les régions. Une URL créée dans une région peut prendre quelques millisecondes pour être disponible dans une autre. Ce compromis améliore considérablement la latence d'écriture et la disponibilité du système, qui sont plus critiques pour cette application que la cohérence globale immédiate. 2. **Coût vs. Performance** : Nous utilisons un cache Redis en mémoire de grande taille et coûteux pour répondre à l'exigence stricte de latence p99 <10 ms. Une solution basée sur disque, moins chère, ne pourrait pas satisfaire cette exigence de performance fondamentale. Nous échangeons un coût opérationnel plus élevé contre une faible latence garantie sur le chemin de lecture critique. 3. **Complexité vs. Évolutivité (KGS)** : Nous avons introduit un service de génération de clés distinct (KGS) au lieu de générer des hachages ou des chaînes aléatoires à la volée. Cela ajoute un composant supplémentaire à construire et à maintenir, augmentant la complexité du système. Cependant, cela élimine complètement les points chauds de la base de données et la logique de vérification des collisions sur le chemin d'écriture, ce qui est un compromis crucial pour garantir un débit élevé et des écritures à faible latence à grande échelle.

Résumé Je propose un raccourcisseur d'URL globalement distribué et privilégiant le cache, avec : un chemin de redirection léger en périphérie (CDN + fonction edge + cache local) pour répondre à l'exigence de latence p99 de redirection <10 ms ; un magasin primaire durable et multi-régions pour les correspondances canoniques ; un allocateur d'ID distribué pour générer des codes courts uniques encodés en base62 (<=7 caractères) ; un pipeline d'analyse asynchrone (Kafka/Kinesis → processeurs de flux → magasin OLAP) qui est strictement découplé du chemin de redirection ; et une réplication et un basculement multi-régions pour la disponibilité lors d'une panne complète de centre de données. A. Architecture de haut niveau (composants et interactions) - Couche Edge (CDN) : CDN Cloud (par ex., Amazon CloudFront, Fastly) devant toutes les requêtes GET /{code} de redirection. La plupart des requêtes sont servies à partir du cache edge du CDN avec une réponse 301/302 mise en cache. - Fonction Edge (CloudFront Function / Fastly Compute / Lambda@Edge) : en cas de cache manqué, une petite fonction edge invoque une API de redirection régionale (via un court RPC/HTTP) pour récupérer l'URL de destination canonique et renvoyer un 301/302. La fonction edge ajoute une logique minimale pour choisir le bon TTL de cache et gérer les codes supprimés/manquants. - API de redirection régionale / Couche de cache de lecture : serveurs de lecture sans état dans chaque région qui consultent d'abord un cache régional en mémoire (cluster Redis / ElastiCache ou Memcached), puis se rabattent sur le magasin clé-valeur durable si nécessaire. - Magasin clé-valeur durable (DB primaire) : DynamoDB Global Tables ou Cassandra (multi-régions) qui stockent short_code -> long_url et métadonnées comme source de vérité canonique. - Service d'allocation d'ID (allocateur de plage) : un petit service qui distribue des blocs d'ID aux serveurs de l'API d'écriture pour la génération de codes courts locaux (assure l'unicité sans verrou central par écriture). - API d'écriture : service qui gère les requêtes de création, réserve/génère le short_code (via bloc d'ID), persiste dans la DB primaire et propage une invalidation aux caches et au CDN. - Invalidation et propagation du cache : lors de la création/mise à jour/suppression, l'API d'écriture met à jour les caches régionaux et invalide les entrées edge du CDN via l'API d'invalidation du CDN ou en écrivant des en-têtes cache-control et en utilisant un jeton de version dans l'URL si nécessaire. - Pipeline d'analyse (asynchrone) : les événements de redirection sont enregistrés de manière asynchrone (pas dans le chemin de redirection synchrone). Les loggers edge ou les serveurs de lecture régionaux envoient des événements de clic légers à un bus de messages (Kafka / Kinesis). Le traitement de flux (Flink / Spark Streaming) agrège et écrit dans un magasin d'analyse (ClickHouse / BigQuery) et dans des compteurs pré-agrégés dans un magasin optimisé en lecture pour les tableaux de bord. - API et UI de tableau de bord : lit les analyses agrégées à partir des magasins OLAP/agrégés et sert les tableaux de bord utilisateur. Les requêtes de tableau de bord n'atteignent jamais le chemin de redirection. B. Stratégie de génération d'URL Objectifs : unicité, compacité (<=7 caractères alphanumériques), haut débit, faible contention. Approche choisie : ID numériques séquentiels alloués en blocs d'ID distribués, encodés en base62 pour produire le code court. - Pourquoi des ID séquentiels en base62 : la base62 (a–z, A–Z, 0–9) donne 62^7 ≈ 3,52 × 10^12 codes possibles avec des chaînes allant jusqu'à 7 caractères — bien plus que les besoins prévus sur la durée de vie. Les ID séquentiels s'encodent de manière compacte et sont faciles à inverser en valeurs numériques si nécessaire. Le mappage déterministe évite les collisions de hachage. - Implémentation de l'allocation d'ID : un allocateur central distribue des plages d'ID monotones croissants (par ex., blocs de 1M) à chaque cluster de serveurs d'écriture. Chaque serveur d'écriture émet des ID locaux à partir de son bloc sans coordination distante, garantissant l'unicité et une latence très faible. L'allocateur lui-même est petit et peut être sauvegardé par un magasin hautement disponible (RDS ou un compteur léger basé sur ZooKeeper/etcd) et n'est utilisé que pour le rechargement des blocs (faible QPS). - Encodage : ID numérique -> chaîne base62. Si l'ID numérique < 62^7, la longueur de l'encodage est <=7. Avec 100 millions de nouveaux raccourcissements/mois (1,2 milliard/an), la capacité de 62^7 donne plus de 2900 ans d'espace. - Gestion des collisions : aucune attendue car les ID numériques sont uniques. Néanmoins, l'API d'écriture utilise une insertion conditionnelle contre la DB primaire (PUT avec clé primaire == short_code) et une nouvelle tentative en cas de conflit rare dans la DB primaire (ne devrait pas arriver si l'allocateur est correct). Pour les alias personnalisés demandés par l'utilisateur, vérifiez et renvoyez une erreur s'ils sont déjà pris. - Déduplication optionnelle : maintenir éventuellement un index de hachage secondaire (par ex., SHA-256 de long_url) pour renvoyer un code court existant si la même URL a été raccourcie auparavant par le même utilisateur ; ceci est un comportement au niveau de l'application et est facultatif. C. Modèle de données et stockage Choix du magasin de données primaire : DynamoDB Global Tables (géré, multi-régions, latence de lecture/écriture à un chiffre en ms), ou Apache Cassandra / ScyllaDB (auto-géré multi-régions) comme choix canoniques. Je recommande DynamoDB Global Tables pour des opérations plus rapides et une réplication multi-régions plus simple, sauf si vous devez être cloud-agnostique. Schéma de la table de mappage primaire (optimisé clé-valeur) : - Nom de la table : URL_Mapping - Clé primaire : short_code (chaîne, PK) - Attributs : long_url (texte), user_id (chaîne), created_at (horodatage), custom_alias_flag (booléen), deleted_flag (booléen), metadata (JSON/Map sparse), analytics_enabled (booléen), version (int) - Index secondaires (optionnels) : user_id -> liste de short_codes (GSI) pour l'interface de gestion ; long_hash -> short_code (pour la déduplication si désiré) Estimations de stockage : supposer que chaque enregistrement stocke en moyenne 200 octets (short_code ~7 octets, URL moyenne 200 ? mais nous pouvons compresser ; supposer 200-400 octets de manière conservatrice). À 100 millions de nouvelles lignes/mois : 100M * 200 octets = 20 Go/mois. Annuel ≈ 240 Go. Dix ans ≈ 2,4 To. DynamoDB/Cassandra peuvent facilement gérer cette échelle. Magasins d'analyse : les événements de clic bruts vont dans des systèmes d'ajout uniquement (Kafka/Kinesis) puis dans un magasin d'analyse à long terme (ClickHouse ou BigQuery) pour l'agrégation et les tableaux de bord. Les compteurs pré-agrégés (par short_code par intervalle de temps) peuvent être stockés dans ClickHouse et les compteurs chauds mis en cache dans Redis pour les requêtes de tableaux de bord. D. Optimisation du chemin de lecture (atteindre <10 ms p99 de redirections) L'objectif est de servir les redirections au 99e centile en moins de 10 ms depuis l'arrivée de la requête jusqu'à l'émission du 301/302. Techniques utilisées : 1) CDN + Cache Edge (optimisation principale) : mettre en cache les réponses 301 complètes aux bords du CDN pour la quasi-totalité des requêtes. Définir des TTL très longs (effectivement sans expiration) car les mappages n'expirent pas, mais prendre en charge l'invalidation immédiate lorsqu'un mappage est mis à jour/supprimé. - Avec un succès du cache CDN, la latence vers le client est généralement <10 ms dans le monde entier. 2) Très petite fonction edge pour la recherche en cas de cache manqué : CloudFront Function ou edge compute de Fastly pour minimiser la surcharge d'exécution (~sous-ms). Si le cache est manqué, la fonction edge appelle une API de redirection régionale via une courte connexion TCP (keepalive) et renvoie un 301 au CDN. 3) Cache de lecture régional (Redis dans chaque région) : le cache régional est un magasin privilégiant la mémoire pour les recherches de mappage ; un GET Redis typique <1 ms. Taux de succès du cache cible : >=99% pour les codes chauds. Utiliser l'éviction LFU/LRU et la taille pour conserver l'ensemble de travail. - Exemple de dimensionnement du cache : supposer un RPS mondial maximal = 40k lectures/sec ; ensemble de travail des 50 millions de codes supérieurs (queue chaude) — stocker les paires short_code->long_url (moyenne 200 octets). Mémoire = 50M * 200 octets ≈ 10 Go. Un cluster Redis multi-shards modeste (par ex., 4-8 nœuds de 32 Go chacun) par région peut gérer cela. 4) Accès à la DB d'origine uniquement en cas de cache manqué : DynamoDB GetItem sur une seule ligne prend généralement quelques ms (1-10 ms) mais nous concevons pour éviter d'être dans le chemin critique pour le p99 en mettant en cache massivement. 5) Garder la fonction edge + le chemin HTTP minimaux : utiliser HTTP/2 ou HTTP/3 entre le CDN et l'origine pour réduire la latence de négociation et permettre la réutilisation des connexions. 6) Anycast local + routage géo-conscient : envoyer le client au edge/région le plus proche pour maintenir un faible RTT. Mesure et SLA : tester avec du trafic synthétique et des budgets de latence du 99e centile alloués : succès CDN (cible <5 ms), fonction edge + Redis <10 ms, secours d'origine acceptable pour les faibles centiles mais sera surveillé et ajusté. E. Chemin d'écriture : création et persistance 1) Le client effectue une requête POST /create (ou via l'UI) à l'API d'écriture (point d'accès conscient de la région). La couche API d'écriture est sans état et auto-scalée. 2) L'API d'écriture obtient un ID numérique de son bloc alloué localement (allocateur de plage). Si le bloc est épuisé, elle demande un nouveau bloc à l'allocateur. 3) Encoder l'ID numérique en short_code base62. 4) Persister dans la DB primaire avec une insertion conditionnelle : PutItem(short_code, long_url, metadata) avec une expression conditionnelle indiquant que le short_code n'existe pas (empêche l'écrasement accidentel d'un alias personnalisé). Assurer une écriture atomique pour la durabilité. 5) Après une écriture réussie : - Mettre à jour le cache de lecture régional (write-through) afin que les redirections ultérieures atteignent le cache. - Envoyer une requête de pré-chauffage du cache CDN ou publier une invalidation pour ce short_code auprès du CDN afin que le nouveau mappage soit immédiatement mis en cache aux bords (ou exploiter le cache-control + versioning du CDN pour le rendre efficace). 6) Renvoyer le short_code créé à l'utilisateur. Durabilité et cohérence : écriture synchrone dans la DB primaire avec réplication entre les régions (tables globales DynamoDB ou Cassandra avec réplication multi-DC). Si vous utilisez DynamoDB, le modèle de cohérence peut être éventuellement cohérent pour les lectures, mais les écritures sont durables et répliquées. Chiffres opérationnels : QPS d'écriture moyen ≈ 40 écritures/sec (100M/mois ≈ 38,6/s). Des pics de rafales sont possibles ; le pipeline d'écriture est facile à faire évoluer horizontalement. F. Stratégie de mise à l'échelle (mise à l'échelle horizontale) - Serveurs API / Redirection sans état : mise à l'échelle horizontale automatique derrière un équilibreur de charge global (ALB / GCLB). Garder les serveurs sans état pour qu'ils soient faciles à faire évoluer. - Allocateur d'ID : faible QPS — mise à l'échelle en le rendant tolérant aux pannes (actif/passif + compteur persisté ou allocation de plage déléguée). Allouer des blocs plus grands pour réduire la charge de l'allocateur. - Caches : clusters Redis/ElastiCache par région, sharded (hachage cohérent). Ajouter des shards pour augmenter le débit de mémoire. - DB primaire : mise à l'échelle automatique de DynamoDB ou cluster Cassandra qui peut ajouter des nœuds et augmenter le débit. Choisir les tailles d'instance et le facteur de réplication pour répondre à la capacité de lecture/écriture. - Bus de messages (Kafka/Kinesis) : partitionner le flux de clics par hachage de short_code pour mettre à l'échelle l'ingestion. Utiliser suffisamment de partitions pour répondre au débit de pointe (par ex., si les redirections de pointe sont de 38k RPS générant 38k événements/sec, provisionner les partitions et les brokers Kafka pour gérer ~50–100k événements/s avec un facteur de réplication de 3). - Calcul d'analyse : faire évoluer les clusters Flink / Spark horizontalement en fonction du volume d'événements. - Le CDN évolue automatiquement ; la configuration du CDN doit être ajustée pour les taux de requêtes. G. Fiabilité et tolérance aux pannes Objectifs : survivre à la mise hors ligne d'un centre de données entier, garantir l'absence de perte de données. - Déploiement multi-régions : déployer au moins deux régions actives (multi-actives) avec routage global. Utiliser un équilibrage de charge global + des vérifications de santé pour router autour d'une région défaillante. - Réplication de la DB primaire : DynamoDB Global Tables fournit une réplication active-active entre les régions ; Cassandra/Scylla peut être configuré avec un facteur de réplication entre les centres de données. Cela assure la durabilité si un DC est perdu. - Caches régionaux au chaud en cas de panne : lorsqu'une région tombe en panne, le trafic est routé vers la région suivante qui aura son propre cache. Le démarrage à froid d'une région après un basculement peut entraîner plus de lectures d'origine jusqu'à ce que les caches soient chauds, mais la disponibilité est préservée. - Tolérance aux pannes de l'allocateur d'ID : état de l'allocateur persisté dans un magasin hautement disponible ; allouer de grands blocs pour réduire le besoin d'accéder à l'allocateur en cas de panne. - Réplication du bus de messages : Kafka avec un facteur de réplication >=3 entre les racks/régions ou Kinesis géré avec réplication inter-régions pour la durabilité. - Vérifications de santé et basculement automatisé : surveillance active, disjoncteurs, limitation de débit pour éviter la surcharge pendant le basculement. - Sauvegardes : instantanés périodiques de la DB primaire et exportations de métadonnées. Pour DynamoDB, activer la récupération à point nommé ; pour Cassandra, instantanés planifiés. H. Pipeline d'analyse (collecter/traiter/servir sans impacter les redirections) Principe de conception : les écritures d'analyse doivent être asynchrones et ne jamais bloquer les redirections. 1) Génération d'événements légers : l'edge (CDN/fonction edge) émet un petit événement pour chaque redirection (short_code, horodatage, ip_client ou tag_geo, référent, user-agent). Pour minimiser la latence de redirection, l'émission se fait via un push très rapide de type UDP vers un proxy local ou via une mise en lot en mémoire dans le serveur de lecture et envoyée de manière asynchrone. 2) Bus de messages : les événements sont poussés vers des topics Kafka ou Kinesis partitionnés par short_code (ou haché) pour prendre en charge le traitement parallèle évolutif. Le producteur doit être asynchrone et non bloquant ; si le buffer Kafka local est plein, il se rabat sur l'échantillonnage ou supprime les champs de faible valeur pour garantir que la latence de redirection n'est pas affectée. Les producteurs utilisent une mise en tampon locale et des politiques de contre-pression. 3) Traitement de flux : Flink / Kafka Streams / Spark Streaming consomme les événements, les enrichit (recherche geo-IP, analyse UA) et calcule des agrégats en temps réel (nombre de clics, distribution géographique, référents) à granularité minute/heure. Pré-agréger par short_code par fenêtre de temps. 4) Magasin OLAP et agrégats : écrire les données agrégées dans ClickHouse ou BigQuery pour des requêtes analytiques rapides et un stockage à long terme. Pour servir les tableaux de bord, stocker les agrégats récents dans un magasin de lecture rapide (Redis ou Druid) pour des requêtes interactives. 5) API de tableau de bord : lit uniquement à partir du magasin d'agrégats/OLAP ; aucune requête directe du magasin d'analyse vers le chemin de redirection. Implémenter des limites de débit et des quotas par utilisateur pour les requêtes de tableau de bord. 6) Échantillonnage et journalisation hiérarchisée : pour les short_codes à trafic extrêmement élevé, échantillonner éventuellement les événements pour réduire la charge du pipeline tout en préservant des analyses représentatives. Exemple de performance : redirections de pointe ~40k/s -> événements 40k/s -> ingestion Kafka facilement gérable avec 100 partitions et quelques brokers. Les processeurs de flux évoluent horizontalement pour gérer ce volume et écrire des agrégats résumés chaque minute dans ClickHouse. I. Principaux compromis (au moins trois) avec justification 1) Mise en cache edge CDN vs cohérence immédiate pour les suppressions/mises à jour - Compromis : l'utilisation d'un cache edge CDN à longue durée de vie offre une latence de redirection très faible, mais rend la propagation des mises à jour/suppressions légèrement plus complexe et pas instantanée partout. - Justification : le SLA de latence de redirection est strict (<10 ms p99). Les opérations typiques pour modifier/supprimer une URL courte sont rares par rapport aux redirections. Nous privilégions une latence ultra-faible pour les redirections et acceptons une invalidation de cache légèrement retardée (nous fournissons des API d'invalidation immédiate pour les cas importants). Nous incluons également un jeton de version ou une stratégie d'invalidation TTL courte pour les mises à jour critiques. 2) Allocation d'ID séquentiels (blocs de plage + base62) vs schéma de hachage/aléatoire complet - Compromis : l'allocation séquentielle avec des blocs nécessite un petit service d'allocation et une gestion prudente lors du basculement inter-régions, tandis que la génération aléatoire/par hachage peut être entièrement sans état mais nécessite une résolution de collision ou une longueur de code plus importante pour réduire les collisions. - Justification : les ID séquentiels produisent des codes compacts et très courts de manière déterministe et évitent la gestion des collisions au moment de l'écriture. Avec l'allocation par blocs, la charge de l'allocateur est minimale et évolutive. Compte tenu de l'espace de clés extrêmement vaste (62^7), nous n'avons pas besoin d'aléatoire pour éviter les collisions. 3) DynamoDB (géré, multi-régions) vs Cassandra auto-hébergé - Compromis : DynamoDB simplifie la charge opérationnelle et offre une réplication multi-régions gérée, mais peut être plus coûteux et un peu moins flexible dans les modèles de requête par rapport à Cassandra/Scylla auto-hébergé. - Justification : le modèle d'accès du système est des lectures/écritures simples par clé primaire ; nous valorisons la simplicité opérationnelle, la fiabilité et la mise à l'échelle automatique et recommandons donc DynamoDB Global Tables, sauf si les contraintes de coût forcent Cassandra. 4) Caching synchrone en write-through vs propagation éventuelle vers les caches - Compromis : le write-through synchrone vers les caches augmente légèrement la latence d'écriture mais assure une disponibilité immédiate dans les caches de lecture ; la propagation éventuelle réduit la latence d'écriture mais peut entraîner une courte fenêtre où les redirections manquent. - Justification : les écritures ont un faible QPS (≈40/s), donc effectuer une écriture dans le cache lors de la création est acceptable pour garantir que les liens nouvellement créés sont immédiatement disponibles pour les redirections et éviter les misses de cache à froid pour les codes courts nouvellement créés. Considérations opérationnelles et télémétrie - Surveillance : latence de redirection p99, taux de succès du cache, RPS d'origine, latence d'écriture, décalage du bus de messages, décalage du pipeline d'analyse. Alertes pour le décalage de réplication inter-DC. - Planification de la capacité : prévoir une marge de sécurité de 10x par rapport au pic. Exemples de chiffres : - QPS de lecture (moyenne) : 3 858 RPS = 10 milliards/mois. Hypothèse de pic 10x => ~38,6k RPS. - Cible de succès edge CDN : 99% → RPS d'origine ≈ 386 RPS. Caches régionaux dimensionnés pour conserver l'ensemble de travail chaud. - Dimensionnement du cache : pour conserver les 50 millions de clés supérieures à 200 octets chacune → 10 Go ; utiliser plusieurs shards par région. - Débit Kafka : à un pic de 40k événements/s, avec une taille moyenne d'événement de 500 octets => ~20 Mo/s d'ingestion ; avec un facteur de réplication de 3 et une marge, prévoir ~60 Mo/s de débit de cluster. - Débit de la DB primaire : écritures ~40/s, lectures depuis l'origine après misses de cache ~386/s agrégées (ou réparties par région). La mise à l'échelle automatique de la capacité de DynamoDB supporte facilement ces niveaux. Sécurité et fonctionnalités opérationnelles - Limitation de débit et détection d'abus en périphérie pour atténuer le spam ou les bots. - Limitation des écritures d'analyse en cas de surcharge, échantillonnage pour les codes extrêmement chauds. - Contrôles d'accès (OAuth/jetons API) pour la création et la gestion des URL courtes. - Journaux d'audit pour les suppressions afin de respecter la garantie de non-expiration sauf si explicitement supprimé. Conclusion Cette conception privilégie la latence de redirection et la disponibilité via la mise en cache edge CDN + une logique edge minimale, un stockage multi-régions durable pour les mappages permanents, un schéma d'allocation d'ID et d'encodage base62 simple et robuste (garantissant aucune collision et <=7 caractères), et un pipeline d'analyse entièrement asynchrone afin que les analyses ne dégradent jamais les performances de redirection. L'architecture évolue horizontalement, survit aux pannes complètes de DC via la réplication multi-régions, et fournit des leviers opérationnels (dimensionnement du cache, invalidation CDN, échantillonnage) pour équilibrer les coûts par rapport aux performances.