Concevoir un service mondial de raccourcissement d'URL

### 1. Architecture de haut niveau Le système est conçu comme un service mondialement distribué et multi-régions pour garantir une faible latence et une haute disponibilité. Chaque région majeure (par exemple, US-East, EU-West, AP-Southeast) héberge une pile complète de Point of Presence (PoP). **Composants :** 1. **Répartiteur de charge mondial (GLB) :** Utilise un routage DNS basé sur la latence pour diriger les utilisateurs vers le PoP régional sain le plus proche. 2. **Pile PoP régionale :** * **Passerelle API :** Termine le TLS, authentifie les requêtes et les achemine vers le service backend approprié. * **Service de redirection :** Un service léger et hautement évolutif qui gère les requêtes `GET /{alias_court}`. Il est optimisé pour la vitesse. * **Service d'écriture :** Gère la création de liens (`POST /api/v1/links`), y compris la validation d'alias personnalisés et la génération d'identifiants uniques. * **Service d'analyse :** Fournit l'accès aux statistiques des liens via `GET /api/v1/links/{alias_court}/stats`. 3. **Infrastructure de données :** * **Base de données mondiale :** Une base de données distribuée et fortement cohérente pour la cartographie principale des liens. * **Cache régional :** Un cache en mémoire dans chaque région pour les liens populaires. * **Pipeline d'analyse :** Une file d'attente de messages pour l'ingestion d'événements, un processeur de flux pour l'agrégation et une base de données NoSQL pour le stockage et la diffusion des données d'analyse. **Flux de données :** * **Création de lien :** La requête `POST` d'un utilisateur est acheminée vers le service d'écriture le plus proche. Le service génère ou valide un alias et écrit le mappage `alias_court -> URL_longue` dans la base de données mondiale. L'écriture est répliquée de manière synchrone dans toutes les régions en moins de 2 secondes. * **Redirection :** Une requête `GET` est acheminée vers le service de redirection le plus proche. Il vérifie d'abord le cache régional. En cas de succès du cache, il émet immédiatement une redirection 301 et envoie de manière asynchrone un événement de clic à la file d'attente d'analyse. En cas d'échec, il interroge la réplique locale de la base de données mondiale, remplit le cache, puis effectue la redirection et l'enregistrement de l'événement. * **Analyse :** Les événements de clic de toutes les régions sont publiés dans une file d'attente de messages centrale. Un processeur de flux consomme ces événements, les agrège en statistiques par fenêtre temporelle (clics totaux, clics sur 24h, pays), et écrit les résultats dans la base de données d'analyse. ### 2. Choix de stockage * **Mappages de liens (Stockage principal) :** * **Technologie :** Une base de données SQL distribuée mondialement comme Google Cloud Spanner ou CockroachDB. * **Justification :** Ce choix est motivé par le besoin de cohérence forte sur les redirections et l'exigence de propagation des écritures mondiales inférieure à 2 secondes. Ces bases de données fournissent une réplication synchrone et des lectures régionales à faible latence, justifiant leur coût plus élevé pour la fonction commerciale principale. L'`alias_court` sert de clé primaire pour des recherches rapides. * **Liens populaires mis en cache :** * **Technologie :** Un cache distribué régional en mémoire comme Redis Cluster. * **Justification :** Avec 8 milliards de lectures quotidiennes et un trafic fortement déséquilibré, un cache est essentiel pour atteindre la cible de latence P95 <80 ms et protéger la base de données. Chaque région maintient son propre cache en utilisant un modèle de cache-aside. * **Données d'analyse :** * **File d'attente d'ingestion :** Apache Kafka ou AWS Kinesis. Cela découple le chemin de redirection à haut débit du traitement analytique et fournit un tampon durable pour les événements de clic. * **Base de données de service :** Un magasin NoSQL à colonnes larges comme Apache Cassandra ou ScyllaDB. Il est optimisé pour la charge de travail d'agrégation de séries temporelles à forte écriture de l'analyse et est plus rentable à grande échelle pour ces modèles de requête qu'une base de données relationnelle. ### 3. Génération d'identifiants et stratégie d'alias Nous utiliserons un alias de 7 caractères de l'alphabet `[a-zA-Z0-9]`, fournissant `62^7` (plus de 3,5 billions) combinaisons uniques. * **Génération d'identifiants :** Un service d'arrière-plan pré-génère un grand pool d'identifiants uniques aléatoires et les stocke dans une file d'attente dédiée (par exemple, une liste Redis). Le service d'écriture récupère simplement un identifiant pré-généré de ce pool lors de la création d'un nouveau lien. Cette approche est rapide, évolutive et évite les vérifications de collision à la volée lors d'une requête utilisateur. * **Gestion des alias personnalisés :** Lorsqu'un utilisateur soumet un alias personnalisé, le service d'écriture tente de l'`INSERT` dans la base de données mondiale. La colonne `alias_court` est la clé primaire avec une contrainte d'unicité. Cela gère atomiquement l'opération de vérification et de définition ; si l'alias est déjà pris, la base de données rejette l'écriture, et le service renvoie une erreur `409 Conflict` à l'utilisateur. ### 4. Conception de l'API * **Créer un lien :** `POST /api/v1/links` * **Corps :** `{ "long_url": "...", "custom_alias": "..." (optionnel), "expires_at": "..." (optionnel) }` * **Réponse :** `201 Created` avec `{ "short_url": "...", "long_url": "..." }` * **Redirection :** `GET /{alias_court}` * **Réponse :** `301 Moved Permanently` avec l'en-tête `Location: {url_longue}` pour les liens permanents. `404 Not Found` si l'alias n'existe pas ou a expiré. * **Obtenir les analyses :** `GET /api/v1/links/{alias_court}/stats` * **Réponse :** `200 OK` avec `{ "total_clicks": ..., "clicks_last_24h": ..., "top_countries": [...] }` ### 5. Approche de mise à l'échelle * **Clés chaudes :** Une stratégie de mise en cache à plusieurs niveaux est employée. Pour les liens extrêmement viraux, la réponse de redirection `301` peut être mise en cache au niveau du CDN. La défense principale est le cache Redis régional, qui absorbera la majorité du trafic déséquilibré. * **Partitionnement :** La base de données mondiale (Spanner/CockroachDB) gère automatiquement le partitionnement des données de liens par sa clé primaire (`alias_court`). La base de données d'analyse (Cassandra) sera partitionnée par `alias_court` pour co-localiser toutes les statistiques d'un lien donné, permettant des requêtes efficaces. * **Trafic multi-régions :** Le GLB garantit que les utilisateurs sont dirigés vers le PoP le plus proche pour une faible latence. L'architecture est active-active, car les écritures peuvent être gérées par n'importe quelle région et sont répliquées mondialement par la base de données. Cette conception maximise l'utilisation des ressources et la disponibilité. ### 6. Stratégie de fiabilité * **Basculement :** Le GLB effectue des vérifications de santé et redirigera automatiquement le trafic loin de toute région non saine. Au sein d'une région, les répartiteurs de charge achemineront le trafic autour des instances de service défaillantes. * **Réplication des données :** La base de données mondiale est configurée pour répliquer les données sur plusieurs zones de disponibilité et régions, offrant une résilience contre les défaillances d'instances et de régions. Le cluster Cassandra pour l'analyse sera également déployé dans plusieurs régions. * **Sauvegarde :** Des instantanés automatisés et périodiques des bases de données primaires et d'analyse sont effectués et stockés dans un stockage d'objets durable (par exemple, AWS S3) pour la reprise après sinistre. * **Dégradation gracieuse :** Le système est conçu de telle sorte qu'une défaillance du pipeline d'analyse non critique n'affectera pas la fonctionnalité de redirection principale. Le service de redirection continuera de traiter les requêtes même s'il ne peut pas publier d'événements dans la file d'attente de messages. ### 7. Compromis et alternatives rejetées * **Alternative 1 : Génération d'identifiants basée sur le hachage (Rejetée). * **Concept :** Générer un identifiant court en hachant l'URL longue. En cas de collision, ajouter un sel et re-hacher. * **Raison du rejet :** Cela ajoute une latence et une complexité imprévisibles au chemin d'écriture. Avec 120 millions d'écritures par jour, la probabilité de collision devient significative, nécessitant plusieurs recherches dans la base de données pour trouver un identifiant unique. La stratégie de pré-génération choisie offre des performances en temps constant pour l'acquisition d'identifiants lors d'une requête utilisateur. * **Alternative 2 : Base de données relationnelle à maître unique (Rejetée). * **Concept :** Utiliser une base de données traditionnelle comme PostgreSQL dans une région primaire unique avec des réplicas en lecture dans d'autres régions. * **Raison du rejet :** Cette conception ne peut pas répondre à l'exigence stricte de propagation des écritures mondiales inférieure à 2 secondes. Le délai de réplication vers des réplicas distants dépasserait fréquemment ce seuil, ce qui signifie qu'un lien nouvellement créé ne serait pas immédiatement disponible pour tous les utilisateurs mondiaux. Le coût plus élevé d'une base de données distribuée mondialement est justifié pour répondre à cette exigence fonctionnelle principale.

SERVICE GLOBAL DE RACCOURCISSEMENT D'URL — CONCEPTION DU SYSTÈME ───────────────────────────────────────── 1. ARCHITECTURE DE HAUT NIVEAU ET FLUX DE DONNÉES ───────────────────────────────────────── Le système est organisé en trois plans : le Plan d'Écriture (création de liens), le Plan de Lecture (redirection) et le Plan d'Analyse (ingestion et interrogation d'événements). Composants majeurs : - Équilibreur de charge Anycast Global / Bord CDN (par ex., Cloudflare ou AWS CloudFront avec Lambda@Edge) - API Gateway + Couche d'authentification (limitation de débit, prévention des abus) - Service de Création de Liens (sans état, évolutif horizontalement) - Service de Redirection (sans état, extrêmement sensible à la latence) - Service de Génération d'ID (producteur distribué de codes courts uniques) - Magasin de Liens Principal (base de données relationnelle répliquée mondialement, par ex., CockroachDB ou AWS Aurora Global) - Cache de Liens Actifs (Redis Cluster, par région) - File d'attente d'Ingestion d'Analyses (Kafka ou AWS Kinesis, par région) - Travailleurs d'Agrégation d'Analyses (processeurs de flux, par ex., Flink ou Kafka Streams) - Magasin d'Analyses (magasin de données colonnaires, par ex., ClickHouse ou Apache Druid) - Service d'Interrogation d'Analyses (API en lecture seule) - Stockage d'Objets pour les sauvegardes à froid (compatible S3) Plan d'Écriture (création de liens) : 1. Le client POSTe vers l'API Gateway régionale la plus proche. 2. L'API Gateway authentifie et limite le débit de la requête, puis la transmet au Service de Création de Liens. 3. Le Service de Création de Liens appelle le Service de Génération d'ID pour obtenir un code court unique (ou valide un alias personnalisé). 4. L'enregistrement est écrit dans le Magasin de Liens Principal avec une forte cohérence dans la région locale ; la réplication globale de la base de données propage l'enregistrement aux autres régions en environ 1 à 2 secondes, satisfaisant le SLA « utilisable dans les 2 secondes à l'échelle mondiale ». 5. Simultanément, le nouveau mappage est poussé vers le cache Redis régional (écriture directe ou invalidation pub/sub) afin que la première redirection dans cette région ne manque pas le cache. 6. Une réponse 201 avec l'URL courte est renvoyée au client. Plan de Lecture (redirection) : 1. Le client émet une requête GET /{codeCourt} vers le nœud périphérique le plus proche. 2. Le nœud périphérique vérifie son propre cache CDN (pour les liens extrêmement actifs, TTL ~5–10 secondes pour respecter la sémantique d'expiration). 3. En cas de manque dans le cache CDN, la requête atteint le Service de Redirection régional. 4. Le Service de Redirection vérifie le cache Redis régional (taux de succès attendu > 99 % pour les liens actifs). 5. En cas de manque dans Redis, le Service de Redirection interroge la réplique de lecture locale du Magasin de Liens Principal. 6. Si le lien est expiré ou introuvable, renvoyer 404/410. 7. Sinon, émettre une redirection HTTP 301 (permanente) ou 302 (temporaire). Utiliser 302 par défaut afin que les navigateurs ne mettent pas en cache indéfiniment, préservant ainsi la précision des analyses. 8. Émettre de manière asynchrone un événement de clic (codeCourt, horodatage, pays dérivé de l'IP, user-agent) vers la File d'attente d'Ingestion d'Analyses régionale. Ceci est un « fire-and-forget » ; cela ne bloque pas la réponse de redirection. Plan d'Analyse : 1. Les sujets Kafka régionaux reçoivent les événements de clic. 2. Les tâches Flink/Kafka Streams consomment les événements et maintiennent des agrégats roulants : clics totaux (compteur), clics dans les dernières 24 heures (fenêtre glissante) et top 5 des pays (esquisse approximative des éléments les plus fréquents, par ex., Count-Min Sketch ou SpaceSaving). 3. Les résultats agrégés sont écrits dans ClickHouse (magasin de données colonnaires optimisé pour l'ajout) toutes les 30 à 60 secondes. 4. Le Service d'Interrogation d'Analyses lit depuis ClickHouse et renvoie les résultats pré-agrégés. Les événements bruts sont également conservés dans ClickHouse pour des requêtes ad hoc. 5. Agrégation des analyses inter-régionales : le cluster Kafka de chaque région reflète les événements vers une région d'analyse centrale via Kafka MirrorMaker 2 ou la réplication inter-régionale Kinesis. Le cluster ClickHouse central détient la vue globale. ───────────────────────────────────────── 2. CHOIX DE STOCKAGE ───────────────────────────────────────── Mappages de liens — CockroachDB (ou Aurora Global DB) : Justification : Nous avons besoin d'une forte cohérence pour les écritures (pour éviter les alias dupliqués) et de lectures à faible latence à l'échelle mondiale. CockroachDB est une base de données SQL distribuée avec prise en charge active-active multi-régions, isolation sérialisable et basculement automatique. Aurora Global DB est une alternative avec un seul écrivain principal et jusqu'à 5 répliques de lecture dans différentes régions avec un décalage de réplication d'environ 1 seconde. L'un ou l'autre satisfait le SLA de propagation globale de 2 secondes. Schéma (simplifié) : liens(codeCourt VARCHAR(12) PK, urlLongue TEXT NOT NULL, idProprietaire BIGINT, creeLe TIMESTAMPTZ, expireLe TIMESTAMPTZ, estPersonnalise BOOLEAN) Index : codeCourt (PK, groupé), idProprietaire + creeLe (pour les tableaux de bord utilisateur). Taille estimée : 120M liens/jour × 365 jours × ~300 octets/ligne ≈ ~13 To/an. Gérable avec partitionnement par creeLe. Cache de Liens Actifs — Redis Cluster (par région) : Chaque région exécute un Redis Cluster avec 3 à 6 shards et réplicas. Entrées du cache : codeCourt → {urlLongue, expireLe}. TTL défini sur min(expiration du lien, 24 heures). Ensemble de travail attendu : les 1 % de liens les plus actifs (~1,2M) représentent ~80 % du trafic. À ~500 octets par entrée, 1,2M d'entrées ≈ 600 Mo par région — très abordable. Nous utilisons une stratégie d'écriture directe lors de la création du lien et une population paresseuse lors de la première absence du cache en redirection. Événements d'Analyse — Kafka + ClickHouse : Kafka conserve les événements de clic bruts pendant 7 jours (rejouabilité). ClickHouse stocke à la fois les événements bruts (partitionnés par date, shardés par codeCourt) et les vues matérialisées pré-agrégées. Le stockage en colonnes et l'exécution vectorisée de ClickHouse le rendent idéal pour les requêtes d'agrégation nécessaires (SOMME, COMPTE, GROUP BY pays, fenêtre glissante). Sauvegardes à Froid — Stockage d'objets compatible S3 : Des instantanés quotidiens du magasin de liens et des exportations hebdomadaires de ClickHouse sont stockés dans le stockage d'objets avec versionnement et réplication inter-régionale pour la reprise après sinistre. ───────────────────────────────────────── 3. STRATÉGIE DE GÉNÉRATION D'ID ET D'ALIAS ───────────────────────────────────────── Format du Code Court : Utiliser 7 caractères d'un alphabet Base62 (a-z, A-Z, 0-9). Base62^7 = ~3,5 billions de combinaisons, dépassant largement tout besoin prévisible (120M/jour × 10 ans = ~438 milliards de liens). Stratégie de Génération d'ID — Compteur Distribué + Encodage : Nous utilisons une approche de compteur distribué plutôt qu'une génération aléatoire pour éviter les tempêtes de collisions à grande échelle. Étape 1 : Chaque instance du Service de Création de Liens acquiert un bloc d'ID auprès d'un service de coordination léger (par ex., un INCRBY Redis ou un service d'ID dédié basé sur ZooKeeper). Chaque instance revendique un bloc de 10 000 ID à la fois, réduisant la surcharge de coordination. Étape 2 : L'ID numérique est encodé en Base62 pour produire le code court. Un code Base62 de 7 caractères peut représenter des ID jusqu'à ~3,5 billions. Étape 3 : Pour empêcher les attaques par énumération et ajouter de l'imprévisibilité, XOR l'ID numérique avec un sel secret avant l'encodage, ou utilisez une fonction de brouillage bijective (chiffrement de Feistel sur l'espace d'ID). Alias Personnalisés : 1. Le client soumet l'alias souhaité (3 à 20 caractères alphanumériques). 2. Le Service de Création de Liens tente une INSERTION avec l'alias personnalisé comme codeCourt en utilisant une contrainte d'unicité dans la base de données. 3. Si l'INSERTION échoue en raison d'une violation de contrainte d'unicité, renvoyer HTTP 409 Conflict avec une suggestion d'essayer un autre alias. 4. Les alias personnalisés contournent entièrement le service de génération d'ID. 5. Les alias personnalisés sont réservés dans une vérification d'espace de noms distincte (liste de grossièretés, mots réservés comme « api », « admin », « health ») avant l'écriture dans la base de données. Gestion des Collisions pour les Codes Générés : Étant donné que nous utilisons un compteur monotone avec un encodage bijectif, les collisions sont structurellement impossibles pour les codes générés. Les collisions ne peuvent se produire que si un code généré correspond par hasard à un alias personnalisé — ceci est géré par la contrainte d'unicité ; le service de génération d'ID incrémente simplement vers l'ID suivant et réessaie (extrêmement rare). ───────────────────────────────────────── 4. CONCEPTION DE L'API ───────────────────────────────────────── Toutes les API sont RESTful sur HTTPS. La limitation de débit est appliquée au niveau de la couche API Gateway (par ex., 100 créations/minute par utilisateur authentifié, 10 créations/minute pour les utilisateurs anonymes). POST /v1/links — Créer un Lien Court Corps de la requête (JSON) : urlLongue: chaîne (obligatoire, doit être une URL valide, max 2048 caractères) aliasPersonnalise: chaîne (facultatif, 3–20 caractères alphanumériques) expireLe: date/heure ISO 8601 (facultatif) idProprietaire: chaîne (facultatif, à partir du jeton d'authentification) Réponse 201 Created : codeCourt: chaîne urlCourte: chaîne (par ex., « https://sho.rt/aB3xY7z ») urlLongue: chaîne expireLe: chaîne ou null creeLe: chaîne Réponse 400 : URL ou format d'alias invalide Réponse 409 : alias personnalisé déjà pris Réponse 429 : limite de débit dépassée GET /{codeCourt} — Redirection Pas de corps de requête. Paramètre de chemin : codeCourt. Réponse 302 Found avec l'en-tête Location défini sur urlLongue. Réponse 404 : code court introuvable. Réponse 410 Gone : lien expiré. Ce point de terminaison est servi au domaine racine (par ex., sho.rt/{codeCourt}) pour une longueur d'URL minimale. GET /v1/links/{codeCourt}/analytics — Récupérer les Analyses Authentification requise (propriétaire ou administrateur). Paramètres de requête : aucun requis (renvoie le résumé par défaut) Réponse 200 : codeCourt: chaîne totalClics: entier clicsDernieres24h: entier topPays: tableau d'objets, chacun avec codePays (ISO 3166-1 alpha-2) et nombreClics, trié par ordre décroissant, max 5 entrées derniereMiseAJour: date/heure ISO 8601 (indique la fraîcheur des analyses) Réponse 404 : lien introuvable. Réponse 403 : non autorisé. GET /v1/links/{codeCourt} — Obtenir les Métadonnées du Lien (point de terminaison utilitaire facultatif) Authentification requise. Réponse 200 : objet de lien complet incluant urlLongue, creeLe, expireLe, estPersonnalise. DELETE /v1/links/{codeCourt} — Supprimer / Désactiver un Lien Authentification requise (propriétaire ou administrateur). Réponse 204 No Content. Supprime logiquement l'enregistrement (définit un horodatage deleted_at) et invalide l'entrée du cache via pub/sub. ───────────────────────────────────────── 5. APPROCHE DE MISE À L'ÉCHELLE ───────────────────────────────────────── Problème des Clés Actives : Une petite fraction de liens (URL virales, campagnes marketing) recevra des millions de redirections par minute. Le sharding Redis naïf place tout le trafic pour une clé sur un seul shard. Atténuation : - Cache local en mémoire dans chaque instance du Service de Redirection (par ex., Caffeine avec un LRU de 10 000 entrées, TTL de 5 secondes). Ceci absorbe les clés les plus actives entièrement dans le processus, éliminant les allers-retours Redis pour les 0,1 % de liens les plus importants. - Mise en cache en périphérie CDN avec un court TTL (5–10 secondes) pour la réponse de redirection elle-même. Avec 8 milliards de redirections/jour, même un taux de succès CDN de 90 % décharge 7,2 milliards de requêtes de l'origine. - Réplicas de lecture Redis : promouvoir les shards de clés actives pour avoir plus de réplicas et router les lectures en mode round-robin. Stratégie de Mise en Cache : Cache à trois niveaux : bord CDN → LRU en mémoire → Redis Cluster → réplique de lecture DB. Population du cache : écriture directe à la création, population paresseuse à la première absence du cache. Invalidation du cache : lors de la suppression ou de l'expiration d'un lien, publier un message d'invalidation sur un canal Redis pub/sub ; toutes les instances du Service de Redirection s'y abonnent et suppriment la clé de leur LRU local. Les entrées CDN expirent naturellement via TTL. Partitionnement : - Magasin de Liens : partitionner par hachage de codeCourt (CockroachDB gère cela automatiquement via le sharding basé sur les plages). Aucune partition active car les codes courts sont uniformément distribués après brouillage bijectif. - Kafka : partitionner les événements de clic par hachage de codeCourt. Ceci garantit que tous les événements pour un lien donné vont dans la même partition, permettant une agrégation d'état par lien sans mélanges. - ClickHouse : shard par codeCourt, partition par date. Les requêtes pour l'analyse d'un seul lien atteignent un seul shard ; les requêtes par plage de temps bénéficient de l'élagage des partitions. Trafic Multi-Régions : Déployer dans trois régions : US-East, EU-West, AP-Southeast (couvre l'Amérique du Nord, l'Europe, l'Asie). - GeoDNS basé sur DNS ou Anycast route les utilisateurs vers la région la plus proche. - Chaque région est entièrement indépendante pour les lectures (Service de Redirection + Redis + réplique de lecture DB). - Les écritures (création de liens) vont au Service de Création de Liens de la région la plus proche, qui écrit dans le nœud local de la base de données distribuée mondialement. CockroachDB se réplique vers d'autres régions en environ 1 à 2 secondes. - Les événements d'analyse sont traités régionalement et reflétés vers un cluster d'analyse central pour l'agrégation mondiale. Esquisse de Capacité : - 8 milliards de redirections/jour = ~92 500 req/s en moyenne, ~300 000 req/s en pointe (facteur 3). - Avec un taux de succès CDN de 90 % : ~30 000 req/s vers l'origine sur 3 régions = ~10 000 req/s par région. - Chaque instance du Service de Redirection peut gérer ~5 000 req/s (principalement des succès de cache, CPU minimal). ~2–4 instances par région en charge moyenne, mise à l'échelle automatique jusqu'à 20+ en pointe. - 120 millions d'écritures/jour = ~1 400 écritures/s en moyenne. Le Service de Création de Liens n'est pas le goulot d'étranglement. ───────────────────────────────────────── 6. STRATÉGIE DE FIABILITÉ ───────────────────────────────────────── Objectif de Disponibilité : 99,99 % = ~52 minutes d'indisponibilité/an. Basculement : - Chaque région exécute plusieurs instances de chaque service sans état derrière un équilibreur de charge régional avec des vérifications de santé (fail open : supprimer les instances non saines en moins de 10 secondes). - Redis Cluster utilise le basculement automatique : si un shard primaire échoue, une réplique est promue en ~15 secondes. Pendant cette fenêtre, le Service de Redirection se rabat sur la réplique de lecture de la base de données (latence légèrement plus élevée mais correcte). - Si une région entière échoue, GeoDNS détecte l'échec via des sondes de santé et redirige le trafic vers la région adjacente la plus proche en 30 à 60 secondes. Les régions restantes doivent absorber la charge ; la mise à l'échelle automatique gère cela. - CockroachDB / Aurora Global DB : basculement automatique vers le nœud d'une autre région si la région primaire est indisponible. Pour Aurora, cela implique une promotion manuelle ou automatisée d'une réplique de lecture en primaire (RTO ~1 minute avec automatisation). Réplication des Données : - Magasin de Liens : réplication synchrone au sein d'une région (au moins 2 nœuds), réplication asynchrone inter-régionale (consensus CockroachDB entre régions, ou Aurora Global DB ~1 s de décalage). Nous acceptons la cohérence éventuelle pour les lectures inter-régionales car le SLA de propagation de 2 secondes est respecté. - Redis : chaque shard a au moins une réplique dans la même région. Pas de réplication Redis inter-régionale (Redis est un cache ; la base de données est la source de vérité). - Kafka : facteur de réplication 3 au sein de chaque région. Mise en miroir inter-régionale pour les analyses uniquement (pas pour la correction des redirections). - ClickHouse : répliqué au sein de la région d'analyse à l'aide de ClickHouse Keeper (remplacement de ZooKeeper). Aucune réplication ClickHouse multi-régionale nécessaire car les analyses sont éventuellement cohérentes. Sauvegarde : - Sauvegardes logiques quotidiennes du Magasin de Liens vers le stockage d'objets (S3), conservées pendant 30 jours. - Exportations complètes hebdomadaires de ClickHouse vers le stockage d'objets, conservées pendant 90 jours. - Données des sujets Kafka conservées pendant 7 jours (agit comme un tampon de rejeu pour la récupération des analyses). - La restauration des sauvegardes est testée mensuellement via des exercices de restauration automatisés dans un environnement de staging. Comportement en Cas de Dégradation : - Si Redis est indisponible : le Service de Redirection se rabat sur les répliques de lecture de la base de données. La latence augmente mais la correction est maintenue. Alerter et mettre à l'échelle les répliques de base de données. - Si la File d'attente d'Analyse est indisponible : les événements de clic sont abandonnés (les analyses sont éventuellement cohérentes ; nous acceptons cette perte). Les redirections ne sont jamais bloquées par des échecs d'analyse. Un disjoncteur dans le Service de Redirection désactive l'émission d'événements si la file d'attente n'est pas saine. - Si le primaire du Magasin de Liens est indisponible : la création de nouveaux liens échoue (renvoyer 503). Les redirections continuent en utilisant les données mises en cache et les répliques de lecture. Ceci est acceptable car la création est moins critique que la disponibilité de la redirection. - Si une région est complètement en panne : basculement GeoDNS vers la région adjacente. Les utilisateurs subissent une latence plus élevée mais le service reste disponible. - La limitation de débit et la détection d'abus au niveau de l'API Gateway empêchent les attaques DDoS de submerger le système. ───────────────────────────────────────── 7. ARBITRAGES CLÉS ET ALTERNATIVES REJETÉES ───────────────────────────────────────── Arbitrage 1 : Redirections 302 vs. 301 Nous avons choisi 302 (redirection temporaire) par défaut. 301 (permanente) permettrait aux navigateurs de mettre en cache la redirection indéfiniment, réduisant la charge sur l'origine. Cependant, 301 rend impossible le suivi des clics répétés d'un même navigateur, casse les analyses et nous empêche de mettre à jour ou d'expirer les liens (le navigateur servirait la redirection mise en cache pour toujours). Le coût du 302 est un trafic d'origine plus élevé, que nous atténuons avec le CDN et la mise en cache en mémoire. Pour les liens explicitement marqués comme permanents par le propriétaire (et sans expiration), nous pourrions offrir le 301 en option, mais le défaut est 302. Arbitrage 2 : Codes Courts Aléatoires vs. Encodage Basé sur Compteur Rejeté : Générer des chaînes Base62 aléatoires de 7 caractères et vérifier les collisions dans la base de données. Raison du rejet : Avec 120 millions de liens/jour et un espace de codes de 3,5 billions, la probabilité de collision commence faible mais augmente avec le temps. Plus important encore, chaque création nécessite une lecture de base de données pour vérifier la collision, puis une écriture — deux allers-retours sous contention. Avec une approche basée sur un compteur, l'ID est garanti unique par construction ; aucune vérification de collision n'est nécessaire. Le service de compteur représente une surcharge de coordination mineure mais est beaucoup moins coûteux que les vérifications de collision de base de données à grande échelle. L'étape de brouillage bijectif conserve l'avantage d'imprévisibilité des codes aléatoires. Arbitrage 3 : Analyses Synchrones vs. File d'attente Asynchrone Rejeté : Écrire les événements de clic de manière synchrone dans la base de données d'analyse pendant la requête de redirection. Raison du rejet : Cela ajouterait 10 à 50 ms de latence à chaque redirection (une écriture ClickHouse ou base de données d'analyse dans le chemin critique), violant le SLA P95 < 80 ms. Cela crée également une dépendance stricte entre la disponibilité de la redirection et la disponibilité des analyses. L'approche de file d'attente asynchrone découple entièrement ces préoccupations. Le coût est que les analyses sont éventuellement cohérentes (décalage de 30 à 60 secondes), ce qui est explicitement acceptable selon les exigences. Arbitrage 4 : Base de Données Globale Unique vs. Base de Données Active-Active Multi-Régions Nous avons choisi une base de données distribuée mondialement (CockroachDB ou Aurora Global) plutôt qu'une base de données primaire dans une seule région avec des répliques de lecture partout. Une base de données primaire dans une seule région nous donnerait des sémantiques de cohérence plus simples mais ferait que toutes les écritures iraient dans une seule région (latence élevée pour les utilisateurs dans d'autres régions créant des liens, et un point de défaillance unique pour les écritures). La base de données distribuée mondialement coûte plus cher et ajoute une complexité opérationnelle, mais elle est justifiée car la latence de création de liens et la disponibilité des écritures sont importantes pour l'expérience utilisateur et l'objectif de disponibilité de 99,99 %. Arbitrage 5 : ClickHouse vs. une Base de Données de Séries Temporelles (par ex., InfluxDB) pour les Analyses Rejeté : InfluxDB ou TimescaleDB pour le stockage des analyses. Raison du rejet : Les bases de données de séries temporelles sont optimisées pour les métriques avec un ensemble de balises fixe. Nos requêtes d'analyse nécessitent des GROUP BY pays flexibles, des fenêtres temporelles arbitraires et potentiellement des jointures avec les métadonnées des liens. Le stockage en colonnes de ClickHouse, l'interface SQL et les vues matérialisées gèrent ces modèles plus naturellement et à plus grande échelle. ClickHouse prend également en charge les agrégations approximatives (quantiles, éléments fréquents) nativement, ce qui est utile pour la requête top 5 des pays à grande échelle. ───────────────────────────────────────── RÉSUMÉ DE LA JUSTIFICATION DU BUDGET ───────────────────────────────────────── Dépenser plus sur : - Clusters Redis multi-régions : la latence de redirection est le SLA principal ; les absences de cache sont coûteuses. - Magasin de Liens distribué mondialement (CockroachDB / Aurora Global) : la correction des redirections et la propagation globale en 2 secondes l'exigent. - Capacité du bord CDN : l'investissement le plus rentable pour la latence et la disponibilité des redirections. - Mise à l'échelle automatique pour le Service de Redirection : le trafic est très variable et par pics. Dépenser moins sur : - Infrastructure d'analyse : la cohérence éventuelle est acceptable ; un seul cluster ClickHouse central avec réplication est suffisant. Pas besoin de réplication d'analyse multi-régionale. - Service de Création de Liens : le volume d'écriture est d'environ 1 400/s, trivialement géré par quelques instances. - Stockage à froid / sauvegardes : le stockage d'objets est bon marché ; sur-provisionner la rétention plutôt que sous-provisionner. - Réplication Redis inter-régionale : Redis est un cache soutenu par la base de données ; la réplication inter-régionale ajoute du coût et de la complexité avec un bénéfice minimal puisque la base de données se réplique déjà.