Concevoir un service mondial de raccourcissement d'URL

1. Architecture de haut niveau et flux de requêtes : **Composants principaux :** * **Passerelle API/Équilibreurs de charge :** Point d'entrée pour toutes les requêtes des utilisateurs, gère le routage, l'authentification et la limitation de débit. * **Service de raccourcissement :** Microservice responsable de la création, de la mise à jour et de la suppression des liens courts. Gère la validation des alias personnalisés et la logique d'expiration. * **Service de redirection :** Microservice optimisé pour une redirection à haut débit et à faible latence. Enregistre les événements de clic. * **Cache distribué (par ex. Cluster Redis) :** Stockage principal pour les mappages `code_court` vers `url_longue` afin de servir les redirections avec une latence minimale. * **Base de données SQL distribuée (par ex. CockroachDB, Google Spanner) :** Stocke la source de vérité faisant autorité pour tous les métadonnées des liens, garantissant l'unicité globale et une forte cohérence. * **File d'attente de messages (par ex. Apache Kafka) :** Ingère les événements de clic à haut volume du service de redirection, le découplant du traitement analytique. * **Processeur analytique (par ex. Apache Flink/Spark Streaming) :** Consomme les événements de clic de la file d'attente de messages, effectue l'agrégation en temps réel et stocke les données. * **Entrepôt de données (par ex. ClickHouse, Snowflake, BigQuery) :** Stocke les données analytiques brutes et agrégées pour les rapports et l'analyse. * **CDN (par ex. Cloudflare, Akamai) :** Distribue les actifs statiques, fournit une résolution DNS globale et peut offrir un routage géographique vers le centre de données le plus proche. **Flux de requêtes :** * **Création de lien court :** 1. L'utilisateur/client envoie une requête à la passerelle API. 2. La passerelle API achemine vers un équilibreur de charge, puis vers le service de raccourcissement. 3. Le service de raccourcissement génère un `code_court` unique (ou valide un alias personnalisé). 4. Il stocke le `code_court`, `url_longue`, `expire_le` et d'autres métadonnées dans la base de données SQL distribuée. 5. Il pousse le nouveau mappage `code_court` -> `url_longue` vers le cache distribué. 6. Le service de raccourcissement renvoie le `code_court` à l'utilisateur. * **Redirection de lien court :** 1. L'utilisateur/client accède à une URL courte, qui est acheminée via CDN/GeoDNS vers le centre de données le plus proche de l'équilibreur de charge. 2. L'équilibreur de charge dirige vers le service de redirection. 3. Le service de redirection vérifie d'abord dans le cache distribué le mappage `code_court` -> `url_longue`. 4. *Cache trouvé :* Si trouvé et actif, il émet immédiatement une redirection HTTP 301/302 vers l'`url_longue`. 5. *Cache manquant :* Si non trouvé, il interroge la base de données SQL distribuée. Si trouvé et actif, il remplit le cache puis redirige. Si non trouvé, expiré ou supprimé, il renvoie une erreur 404. 6. De manière asynchrone, le service de redirection publie un événement de clic (contenant `code_court`, `horodatage`, `pays`, `type_appareil`, `domaine_référent`) dans la file d'attente de messages. * **Traitement analytique :** 1. Le processeur analytique consomme les événements de clic de la file d'attente de messages. 2. Il effectue un traitement en temps réel (par ex. agrégation, enrichissement). 3. Les données brutes et agrégées sont stockées dans l'entrepôt de données pour les rapports. 2. Modèle de données et choix de stockage : * **Liens et alias (Base de données SQL distribuée - CockroachDB/Google Spanner) :** * **Table `liens` :** * `code_court` (VARCHAR, Clé primaire) : L'identifiant court unique. * `url_longue` (VARCHAR) : L'URL d'origine (jusqu'à 500 octets). * `id_utilisateur` (UUID, Indexé, FK) : Optionnel, pour la propriété du lien. * `cree_le` (TIMESTAMP) : Quand le lien a été créé. * `expire_le` (TIMESTAMP, Nullable, Indexé) : Quand le lien doit expirer. * `statut` (ENUM : 'actif', 'expiré', 'supprimé', Indexé) : État actuel du lien. * `est_alias_personnalise` (BOOLEAN) : Vrai s'il s'agit d'un alias défini par l'utilisateur. * `nombre_clics` (BIGINT) : Nombre de clics dénormalisé, cohérent à terme (mis à jour par l'analytique). * *Justification :* Choisi pour des garanties de forte cohérence (crucial pour l'unicité globale de `code_court` et `alias_personnalise`), des propriétés ACID et des capacités natives de réplication multi-régions. Cela simplifie la gestion globale des données et garantit l'intégrité des données. * **Événements analytiques (File d'attente de messages - Apache Kafka, Entrepôt de données - ClickHouse/Snowflake) :** * **Topic Kafka (`evenements_clics`) :** Stocke les messages d'événements de clic bruts (par ex. JSON/Protobuf). * **Entrepôt de données (`clics_bruts` table) :** * `id_evenement` (UUID, Clé primaire) * `code_court` (VARCHAR, Indexé) * `horodatage` (TIMESTAMP, Indexé) * `pays` (VARCHAR, Indexé) * `type_appareil` (VARCHAR) * `domaine_referent` (VARCHAR) * **Entrepôt de données (`clics_agreges` table) :** (par ex. agrégations horaires/journalières) * `code_court` (VARCHAR, PK) * `heure_agregation` (TIMESTAMP, PK) * `pays` (VARCHAR, PK) * `clics_totaux` (BIGINT) * *Justification :* Kafka fournit une ingestion à haut débit et tolérante aux pannes, ainsi qu'un découplage. ClickHouse/Snowflake sont optimisés pour les requêtes analytiques sur des ensembles de données massifs, prenant en charge l'exigence de cohérence éventuelle pour l'analytique. 3. Stratégie de mise à l'échelle pour le trafic fortement axé sur la lecture : * **Cache distribué (Cluster Redis) :** C'est la principale couche de mise à l'échelle pour les redirections. Il stockera les mappages `code_court` vers `url_longue` en mémoire, gérant la grande majorité des 4 milliards de redirections quotidiennes. Le cluster Redis offre une mise à l'échelle horizontale et une haute disponibilité grâce au partitionnement et à la réplication. * **CDN mondial et routage géographique :** Un CDN (par ex. Cloudflare) servira les actifs statiques et fournira un routage intelligent basé sur le DNS (GeoDNS) pour diriger les utilisateurs vers le centre de données géographiquement le plus proche, minimisant ainsi la latence de redirection. * **Services sans état :** Les services de raccourcissement et de redirection sont conçus pour être sans état, permettant une mise à l'échelle horizontale facile en ajoutant plus d'instances derrière des équilibreurs de charge dans chaque région. Les groupes d'auto-mise à l'échelle ajusteront dynamiquement la capacité en fonction du trafic. * **Réplicas de lecture de base de données/Lectures distribuées :** La base de données SQL distribuée gérera intrinsèquement les lectures distribuées sur ses nœuds. Si les taux de réussite du cache sont inférieurs aux attentes, ou pour les liens moins populaires, la capacité de la base de données à mettre à l'échelle les lectures sur son cluster sera cruciale. * **Génération de codes courts :** Pour la création de liens à haut volume, les codes courts peuvent être pré-générés par lots et stockés, ou un service de génération d'ID distribué (par ex. inspiré de Twitter Snowflake) peut être utilisé pour garantir des codes uniques et non séquentiels, évitant ainsi les points chauds de la base de données. 4. Stratégie de fiabilité : * **Basculement :** * **Déploiement multi-régions :** Tous les services critiques (raccourcissement, redirection, base de données, cache, file d'attente de messages) sont déployés dans une configuration actif-actif dans au moins trois régions géographiquement distinctes (par ex. Amérique du Nord, Europe, Asie). * **Basculement au niveau du service :** Les services sont déployés dans des groupes d'auto-mise à l'échelle sur plusieurs zones de disponibilité au sein de chaque région. Les équilibreurs de charge détectent et acheminent automatiquement le trafic loin des instances non saines. * **Basculement de base de données :** La base de données SQL distribuée fournit une réplication multi-régions intégrée et des mécanismes de basculement automatiques (par ex. consensus Raft dans CockroachDB) pour garantir un fonctionnement continu même en cas de défaillance de nœuds ou de zones entières. * **Basculement de cache :** Le cluster Redis fournit une réplication pour la redondance des données et un basculement automatique des nœuds maîtres. * **Basculement de file d'attente de messages :** Les clusters Kafka sont déployés avec réplication (par ex. 3 brokers, facteur de réplication 3) sur plusieurs zones de disponibilité pour tolérer les défaillances de brokers. * **Décisions de cohérence :** * **Forte cohérence (Création de liens/Alias) :** La base de données SQL distribuée garantit une forte cohérence pour l'unicité des `code_court` et `alias_personnalise`. Ceci est essentiel pour éviter les collisions et maintenir l'intégrité des données. * **Cohérence éventuelle (Redirections) :** Le cache distribué fonctionne avec une cohérence éventuelle. Lorsqu'un lien est créé, mis à jour (par ex. modification de `expire_le`) ou supprimé, un événement est publié dans un topic d'invalidation de cache (par ex. Kafka). Les nœuds de cache s'abonnent à ce topic et invalident/mettent à jour leurs entrées. Un court TTL (par ex. 1 à 5 minutes) sur les entrées de cache agit comme une sauvegarde pour éviter une obsolescence indéfinie. * **Cohérence éventuelle (Analytique) :** Les données analytiques sont éventuellement cohérentes dans les 5 minutes, gérées par la file d'attente de messages asynchrone et le traitement en flux. Cela privilégie les performances de redirection par rapport aux mises à jour analytiques immédiates. * **Gestion des pannes régionales :** * **Équilibrage de charge mondial/DNS :** Les services DNS intelligents (par ex. GeoDNS) et les équilibreurs de charge mondiaux détectent automatiquement les pannes régionales et redirigent le trafic vers les régions saines et actives. * **Réplication des données :** La base de données SQL distribuée réplique toutes les données de liens dans les régions actives. Si une région devient indisponible, d'autres régions peuvent continuer à servir les requêtes avec une perte de données et un impact sur la latence minimaux. * **Dégradation gracieuse :** Si le service analytique ou la file d'attente de messages rencontre des problèmes, le service de redirection est conçu pour continuer à fonctionner en mettant en mémoire tampon les événements localement ou, en cas de problèmes extrêmes, en les supprimant, privilégiant ainsi la fonctionnalité de redirection principale. 5. Principaux compromis, goulots d'étranglement et risques : * **Principaux compromis :** * **Cohérence vs Latence :** La forte cohérence pour la création de liens (via SQL distribué) garantit l'intégrité des données mais peut entraîner une latence d'écriture légèrement plus élevée. Pour les redirections, la cohérence éventuelle via un cache hautement optimisé est choisie pour atteindre une latence inférieure à 80 ms. * **Taille du cache vs Coût :** La mise en cache étendue est essentielle pour les performances de redirection mais nécessite des ressources mémoire importantes, entraînant des coûts d'infrastructure plus élevés. Un équilibre doit être trouvé entre le taux de réussite du cache et les dépenses opérationnelles. * **Longueur du code court vs Taille de l'espace de noms :** Les codes plus courts sont plus conviviaux mais augmentent la probabilité de collisions et limitent le nombre total de liens uniques. Un code base62 de 7 à 10 caractères offre un espace de noms vaste et pratique. * **Goulots d'étranglement :** * **Capacité du cache distribué :** Si le cache ne peut pas gérer le débit de lecture maximal ou si l'ensemble de travail actif des liens dépasse sa capacité mémoire, les redirections se rabattront sur la base de données, augmentant la latence et la charge de la base de données. * **Débit d'écriture de la base de données :** Bien que la création de liens soit moins volumineuse que les redirections, 120 millions de liens/jour est considérable. La base de données SQL distribuée doit être capable de gérer cette charge d'écriture entre les régions sans devenir un goulot d'étranglement. * **Latence réseau entre les régions :** La réplication des données inter-régions et les vérifications de cohérence, en particulier pour les opérations d'écriture dans un système distribué mondialement, peuvent introduire une latence inhérente. * **Risques et atténuations :** * **Risque 1 : Collisions de codes courts (en particulier pour la génération aléatoire) :** * *Atténuation :* Utiliser un `code_court` suffisamment long (par ex. 7 à 10 caractères en utilisant base62 : a-z, A-Z, 0-9). Mettre en œuvre une stratégie de génération robuste : pré-générer un grand pool de codes uniques, utiliser un générateur d'ID distribué (par ex. de type Snowflake) pour générer des ID uniques puis les convertir en base62, ou pour les alias personnalisés, effectuer une vérification d'unicité directe dans la base de données avec verrouillage optimiste et tentatives. * **Risque 2 : Obsolescence du cache pour les liens expirés/supprimés :** * *Atténuation :* Mettre en œuvre un mécanisme d'invalidation de cache en temps réel. Lorsqu'un lien change de statut (par ex. `expire_le` atteint, `statut` défini sur 'supprimé'), le service de raccourcissement (ou un travail d'arrière-plan dédié) publie un événement dans un topic Kafka. Toutes les instances du service de redirection et les nœuds de cache s'abonnent à ce topic et invalident immédiatement l'entrée `code_court` correspondante. Un court TTL (par ex. 1 à 5 minutes) sur les entrées de cache agit comme une sauvegarde. * **Risque 3 : Points chauds de base de données dus à une distribution inégale des `code_court` :** * *Atténuation :* Pour les bases de données SQL distribuées, s'appuyer sur leurs capacités internes de partitionnement et de rééquilibrage. Pour les alias personnalisés, l'alias lui-même sert de clé primaire, ce qui devrait bien se répartir. Pour les codes courts générés aléatoirement, s'assurer que l'algorithme de génération produit des codes suffisamment aléatoires pour éviter les clés séquentielles qui pourraient entraîner des points chauds. Surveiller les partitions de base de données et rééquilibrer si nécessaire. 6. Estimation de la capacité : * **Débit :** * **Redirections :** 4 milliards/jour = ~46 300 requêtes/seconde (moyenne), pic ~138 900 requêtes/seconde (3x moyenne). * **Création de liens :** 120 millions/jour = ~1 389 requêtes/seconde (moyenne), pic ~4 167 requêtes/seconde (3x moyenne). * **Ingestion d'événements analytiques :** ~46 300 événements/seconde (moyenne), pic ~138 900 événements/seconde. * **Stockage :** * **Données de liens (Base de données SQL distribuée) :** * Taille moyenne d'enregistrement : ~100 octets (code_court, url_longue, horodatages, statut, etc.). * Nouveaux liens quotidiens : 120 millions * 100 octets = 12 Go. * Total sur 5 ans : 12 Go/jour * 365 jours/an * 5 ans = ~21,9 To. * Avec un facteur de réplication de 3x pour la haute disponibilité/multi-régions : ~65,7 To. * **Données analytiques (Entrepôt de données) :** * Taille moyenne d'un événement : ~100 octets (code_court, horodatage, pays, appareil, référent). * Événements quotidiens : 4 milliards * 100 octets = 400 Go. * Total sur 1 an de rétention : 400 Go/jour * 365 jours/an = ~146 To. * Avec un facteur de réplication de 3x : ~438 To. * **Cache distribué (Cluster Redis) :** * Chaque entrée mise en cache : `code_court` (par ex. 10 octets) + `url_longue` (moyenne 500 octets) = ~510 octets. * Pour mettre en cache 1 milliard de liens actifs (un ensemble de travail raisonnable de liens populaires) : 1 milliard de liens * 510 octets/lien = 510 Go de mémoire cache. C'est une taille importante mais gérable pour un grand cluster Redis partitionné.

## Service de raccourcissement d'URL mondial - Conception du système ### 1. Architecture de haut niveau **Composants principaux :** - **Passerelle API et équilibreur de charge** : Point d'entrée mondial avec routage régional (Amérique du Nord, Europe, Asie) - **Service de liens courts** : Gère la création, la validation et la gestion des alias - **Service de redirection** : Optimisé pour les redirections à haut débit avec une latence minimale - **Couche de cache** : Cache multi-niveaux (CDN périphérique, Redis régional, mémoire locale) - **Magasin de données principal** : Base de données SQL distribuée (PostgreSQL avec sharding) pour les métadonnées de liens - **Pipeline d'analyse** : Flux d'événements (Kafka) → Processeur de flux (Flink/Spark) → Base de données d'analyse (ClickHouse/Druid) - **CDN** : Diffusion de contenu mondiale pour les réponses de redirection - **File d'attente de messages** : Pour les opérations asynchrones (expiration, suppression, analyse) - **Surveillance et Observabilité** : Traçage distribué, métriques, alertes **Flux de requêtes :** *Créer un lien court :* 1. Client → Passerelle API (régionale) 2. Le service de liens courts valide l'entrée, génère un code court ou valide un alias personnalisé 3. Vérifier l'unicité de l'alias dans le cache distribué + la base de données principale 4. Écrire dans la base de données principale (avec réplication) 5. Invalider le cache, publier un événement sur Kafka 6. Retourner le lien court (p95 < 300 ms) *Redirection (Lecture) :* 1. Client → Emplacement périphérique CDN le plus proche 2. Le CDN vérifie le cache local ; en cas de défaut, il achemine vers le cache régional (Redis) 3. Défaut du cache régional → Interroger la base de données principale avec la réplique de lecture 4. Réponse mise en cache au périphérique CDN et au Redis régional 5. Retourner la redirection 301/302 (p95 < 80 ms) 6. Asynchrone : publier l'événement de clic sur Kafka *Analyse :* 1. Événements de clic → Topic Kafka 2. Le processeur de flux agrège par link_id, pays, appareil, référent 3. Écrire les métriques agrégées dans la base de données d'analyse toutes les 1 à 5 minutes 4. Le tableau de bord interroge la base de données d'analyse pour les rapports --- ### 2. Modèle de données et choix de stockage **Table des métadonnées de liens (Base de données principale - PostgreSQL) :** ``` links: - link_id (UUID, clé primaire) - short_code (VARCHAR(10), index unique) - long_url (TEXT, max 500 octets) - user_id (UUID, indexé) - custom_alias (VARCHAR(100), index unique mondial, nullable) - created_at (TIMESTAMP) - expires_at (TIMESTAMP, nullable, indexé) - is_deleted (BOOLEAN, indexé) - is_custom (BOOLEAN) - created_region (VARCHAR(10)) - metadata (JSONB: title, description, tags) ``` **Table des événements d'analyse (Base de données de séries temporelles - ClickHouse) :** ``` click_events: - event_id (UUID) - link_id (UUID, indexé) - timestamp (DateTime) - country (VARCHAR(2)) - device_type (VARCHAR(20)) - referrer_domain (VARCHAR(255)) - user_agent (VARCHAR(500)) - ip_hash (VARCHAR(64)) ``` **Justification des choix de stockage :** - **PostgreSQL (Principal)** : Garanties ACID pour la création de liens, cohérence forte pour l'unicité des alias, éprouvé à grande échelle avec un sharding approprié - **Redis (Cache régional)** : Latence sub-milliseconde pour les liens populaires, prend en charge le TTL pour l'expiration automatique, distribué entre les régions - **ClickHouse (Analyse)** : Optimisé pour l'analyse de séries temporelles, le stockage en colonnes réduit le stockage de 10 à 100 fois, agrégations rapides - **CDN (Cloudflare/Akamai)** : Mise en cache périphérique mondiale, réduit la latence à <80 ms p95, décharge le trafic d'origine - **Kafka (Flux d'événements)** : Découple l'analyse du chemin de redirection, permet la relecture, prend en charge plusieurs consommateurs --- ### 3. Stratégie de mise à l'échelle pour le trafic axé sur la lecture **Architecture de mise en cache (multi-niveaux) :** 1. **Cache CDN périphérique** (Niveau 1) : - Mise en cache des réponses de redirection à l'échelle mondiale - TTL : 24 heures pour les liens actifs, 5 minutes pour les liens expirés - Clé de cache : short_code - Objectif de taux de succès : 95 %+ - Réduit le trafic d'origine de 95 % 2. **Cluster Redis régional** (Niveau 2) : - 3 régions : us-east, eu-west, ap-southeast - Chaque région : cluster Redis avec 6 nœuds (3 principaux, 3 répliques) - Réplication entre les zones de disponibilité - TTL : 1 heure pour les liens, 5 minutes pour les liens expirés - Capacité : 500 Go par région (liens populaires uniquement) 3. **Cache en mémoire locale** (Niveau 3) : - Cache LRU par instance de service (100 Mo) - Réduit les allers-retours Redis pour les 1 % de liens les plus populaires **Stratégie de répliques de lecture :** - Base de données principale dans us-east (maître d'écriture) - Répliques de lecture dans eu-west, ap-southeast (réplication asynchrone, décalage d'environ 100 ms) - Acheminer les lectures vers la réplique la plus proche - Solution de repli vers le principal si la réplique est indisponible **Mise à l'échelle horizontale :** - Service de redirection : Mise à l'échelle automatique à plus de 1000 instances dans les régions - Chaque instance gère environ 4 millions de redirections/jour (4 milliards / 1000) - L'équilibreur de charge distribue en fonction de la latence et de la capacité **Génération de codes courts :** - Encodage Base62 (0-9, a-z, A-Z) pour les codes de 6 caractères - 62^6 = 56 milliards de codes possibles (suffisant pour 120 millions/jour pendant plus de 400 ans) - Générateur d'ID distribué (type Snowflake) avec préfixe régional pour éviter les collisions - Allocation par lots : chaque instance de service pré-alloue 10 000 codes --- ### 4. Stratégie de fiabilité **Basculement et haute disponibilité :** - **Déploiement multi-régions** : Actif-actif dans 3 régions - **Réplication de base de données** : Réplication en continu PostgreSQL avec basculement automatique (Patroni) - **Disjoncteurs** : Empêchent les défaillances en cascade lorsque le cache/la base de données est indisponible - **Dégradation gracieuse** : Si la base de données d'analyse est en panne, continuez de servir les redirections ; mettez en file d'attente les événements localement **Décisions de cohérence :** - **Cohérence forte pour les écritures** : La création de liens utilise des verrous distribués (Redis/Zookeeper) pour l'unicité des alias - **Cohérence éventuelle pour les lectures** : Les réponses de redirection peuvent être obsolètes d'environ 100 ms (acceptable) - **Cohérence éventuelle pour l'analyse** : Fenêtre de 5 minutes acceptable selon les exigences - **Gestion de l'expiration** : Suppression paresseuse (vérification de expires_at à la lecture) + tâche d'arrière-plan (scan toutes les heures) **Gestion des pannes régionales :** 1. **Détection de la panne** : Les vérifications de santé échouent pendant 30 secondes 2. **Basculement** : Acheminer le trafic vers d'autres régions 3. **Opérations d'écriture** : Redirection vers la région principale (us-east) avec repli vers la région locale 4. **Opérations de lecture** : Utiliser les répliques de lecture dans d'autres régions 5. **Récupération** : Synchroniser les données du principal lorsque la région récupère 6. **Surveillance** : Alerter sur l'indisponibilité d'une région, suivre les événements de basculement **Atténuations spécifiques :** - **Défaillance de la base de données** : Basculement automatique de Patroni vers la réplique (RTO < 30 s) - **Défaillance du cache** : Contournement vers la base de données avec limitation du débit pour éviter la meute de loups - **Défaillance du CDN** : Acheminer le trafic vers le cache régional - **Partition réseau** : Supposer que la partition se rétablit ; utiliser des décisions basées sur le quorum - **Corruption des données** : Récupération à un instant T à partir de sauvegardes (instantanés quotidiens) --- ### 5. Compromis clés, goulots d'étranglement et risques **Compromis :** 1. **Cohérence vs. Latence** : Cohérence éventuelle choisie pour l'analyse afin de maintenir la latence de redirection < 80 ms. La cohérence forte pour l'unicité des alias ajoute environ 50 ms mais est nécessaire pour l'exactitude. 2. **TTL du cache vs. Fraîcheur** : Le TTL de 24 heures du CDN réduit la charge d'origine, mais signifie que les liens expirés peuvent rediriger jusqu'à 24 heures. Atténué par un TTL de 5 minutes pour les liens marqués comme supprimés. 3. **Stockage vs. Vitesse de requête** : Dénormaliser les données d'analyse (stocker le pays, l'appareil dans la table des événements) pour permettre des agrégations rapides, en acceptant un surcoût de stockage de 2 à 3 fois. 4. **Autonomie régionale vs. Cohérence mondiale** : Chaque région peut servir les lectures indépendamment, mais les écritures doivent être coordonnées pour l'unicité des alias, ce qui ajoute de la latence. **Goulots d'étranglement :** 1. **Vérification de l'unicité de l'alias** : Verrouillage distribué mondial requis ; peut devenir un point de contention lors des pics d'écriture. Atténuation : Utiliser Redis avec des scripts Lua pour une vérification et une définition atomiques ; sharder par le premier caractère de l'alias. 2. **Débit d'écriture de la base de données** : 120 millions de nouveaux liens/jour = environ 1 400 écritures/seconde. PostgreSQL peut gérer environ 10 000 écritures/seconde par instance, donc besoin de 1 à 2 instances principales. Atténuation : Écriture par lots, utilisation de la mise en commun des connexions (PgBouncer). 3. **Pipeline d'analyse** : 4 milliards de clics/jour = environ 46 000 événements/seconde. Kafka peut gérer cela, mais l'agrégation peut être en retard. Atténuation : Utiliser un processeur de flux (Flink) pour l'agrégation en temps réel ; écrire dans la base de données d'analyse toutes les 1 minute. **Trois risques majeurs et leurs atténuations :** **Risque 1 : Cache stampede lors de l'expiration d'un lien populaire** - *Scénario* : Lien viral avec 1 million de clics/heure expire ; toutes les entrées du cache s'invalident simultanément ; 1 million de requêtes frappent la base de données - *Impact* : Surcharge de la base de données, pics de latence de redirection à plusieurs secondes, violation du SLA - *Atténuation* : - Utiliser une expiration anticipée probabiliste : rafraîchir le cache 5 minutes avant l'expiration réelle - Implémenter la coalescence des requêtes : si plusieurs requêtes frappent un lien expiré, seule la première interroge la base de données - Définir un débit maximal de requêtes à la base de données avec un disjoncteur ; retourner 404 si dépassé - Pré-chauffer le cache pour les liens dont l'expiration est connue **Risque 2 : Collision d'alias distribuée sous partition réseau** - *Scénario* : Partition réseau entre les régions ; deux utilisateurs créent le même alias personnalisé dans des régions différentes ; la partition se rétablit ; conflit de données - *Impact* : Unicité de l'alias violée ; un lien devient inaccessible ; incohérence des données - *Atténuation* : - Utiliser un verrou distribué mondial (Zookeeper/etcd) pour les écritures d'alias ; échouer si le verrou est indisponible - Implémenter la résolution de conflits : le gagnant basé sur l'horodatage (la première écriture gagne) - Tâche d'audit : scanner les alias dupliqués quotidiennement ; alerter en cas de conflits - Exiger que les écritures d'alias passent uniquement par la région principale (accepter une latence plus élevée) **Risque 3 : Perte de données d'analyse lors d'une défaillance du traitement des flux** - *Scénario* : Le consommateur Kafka plante ; les événements ne sont pas traités ; le décalage d'analyse s'agrandit ; la mémoire se remplit ; les événements sont abandonnés - *Impact* : Comptes de clics inexacts ; métriques commerciales peu fiables ; perte de confiance des clients - *Atténuation* : - Utiliser des groupes de consommateurs Kafka avec gestion des offsets ; reprendre à partir du dernier offset validé - Implémenter une file d'attente de lettres mortes pour les événements échoués ; rejouer manuellement - Définir des limites de mémoire sur le tampon d'événements local ; abandonner les événements les plus anciens si plein (avec alertes) - Double écriture d'analyse : Kafka → Processeur de flux ET écritures directes dans la base de données (avec déduplication) - Surveiller le décalage du consommateur ; alerter si le décalage > 5 minutes --- ### 6. Estimations de capacité **Stockage :** *Métadonnées de liens (PostgreSQL) :* - 120 millions de nouveaux liens/jour × 365 jours = 43,8 milliards de liens/an - Par lien : 50 octets (ID, horodatages, drapeaux) + 500 octets (URL longue) + 100 octets (métadonnées) = 650 octets - Année 1 : 43,8 milliards × 650 octets = 28,5 To - Avec une rétention de 3 ans : 85,5 To - Avec réplication (3x) : 256,5 To - Répartis sur 10 instances : 25,6 To par instance (gérable) *Événements d'analyse (ClickHouse) :* - 4 milliards de clics/jour × 365 jours = 1,46 billion d'événements/an - Par événement : 50 octets (ID, horodatages) + 100 octets (pays, appareil, référent) = 150 octets - Année 1 : 1,46 billion × 150 octets = 219 To (non compressé) - Compression ClickHouse : 10-20x → 11-22 To/an - Rétention de 3 ans : 33-66 To (acceptable) *Cache (Redis) :* - Liens populaires (1 % du total) : 438 millions de liens - Par lien en cache : 50 octets (short_code, pointeur long_url) = 50 octets - 438 millions × 50 octets = 22 Go par région - 3 régions : 66 Go au total (rentre dans l'allocation de 500 Go par région) **Débit :** *Débit d'écriture :* - 120 millions de liens/jour ÷ 86 400 secondes = 1 389 écritures/seconde - PostgreSQL : 1 instance principale gère 10 000 écritures/seconde → 1 instance suffisante - Kafka : 1 389 événements/seconde → 1 partition suffisante (Kafka gère plus de 100 000 messages/seconde par partition) *Débit de lecture :* - 4 milliards de redirections/jour ÷ 86 400 secondes = 46 296 lectures/seconde - Pic (3x) : 138 888 lectures/seconde - Taux de succès du cache CDN : 95 % → 6 944 lectures/seconde vers l'origine - Taux de succès Redis : 99 % des échecs → 70 lectures/seconde vers la base de données - PostgreSQL : 1 réplique de lecture par région gère 10 000 lectures/seconde → 1 réplique par région suffisante - Instances du service de redirection : 46 000 lectures/seconde ÷ 100 lectures/seconde par instance = 460 instances (de base) ; 1 389 instances au pic *Débit d'analyse :* - 4 milliards de clics/jour = 46 296 événements/seconde - Kafka : 1 topic, 10 partitions (parallélisme) - Processeur de flux : 10 instances, chacune gère 4 630 événements/seconde - ClickHouse : Inserts par lots toutes les 1 minute ; 46 000 événements/minute = gérable **Bande passante réseau :** *Réponses de redirection :* - 46 000 redirections/seconde × 300 octets (réponse HTTP) = 13,8 Mo/seconde - Pic : 41,4 Mo/seconde - Le CDN absorbe 95 % → 2,1 Mo/seconde vers l'origine au pic - Facilement géré par une connexion de 1 Gbps *Événements d'analyse :* - 46 000 événements/seconde × 500 octets = 23 Mo/seconde - Cluster Kafka : capacité de 10 Gbps → suffisante **Tableau récapitulatif :** | Composant | Capacité | Instances | Notes | |---|---|---|---| | PostgreSQL Principal | 10K écritures/sec | 1 | Shardé pour la croissance future | | Répliques de lecture PostgreSQL | 10K lectures/sec | 3 (1 par région) | Réplication asynchrone | | Clusters Redis | 100K ops/sec | 3 (1 par région) | 6 nœuds chacun | | Service de redirection | 100 redirections/sec | 460 (base), 1 389 (pic) | Mise à l'échelle automatique | | Brokers Kafka | 100K msgs/sec | 3 | Facteur de réplication 3 | | Processeurs de flux | 4 630 événements/sec | 10 | Flink/Spark | | Nœuds ClickHouse | 1M inserts/sec | 3 | Cluster distribué | | Emplacements périphériques CDN | Mondial | 200+ | Cloudflare/Akamai | --- ### Priorités de mise en œuvre 1. **Phase 1** (MVP) : Région unique, PostgreSQL + Redis + CDN, analyse de base 2. **Phase 2** (Échelle) : Multi-régions, répliques de lecture, pipeline d'analyse Kafka 3. **Phase 3** (Optimisation) : Génération d'ID distribuée, mise en cache avancée, analyse ClickHouse 4. **Phase 4** (Renforcement) : Disjoncteurs, ingénierie du chaos, exercices de reprise après sinistre