Concevoir un service mondial de raccourcissement d’URL

1. Architecture de haut niveau avec les principaux composants et flux de données : * **Utilisateur/Client :** Interagit avec le service. * **API Gateway/Load Balancer :** Point d'entrée pour toutes les requêtes, gère le routage, la limitation de débit et la terminaison SSL. * **Service de raccourcissement :** Microservice responsable de la création, de la mise à jour et de la gestion des URL courtes. Interagit avec la base de données de métadonnées de liens et le cache. * **Service de redirection :** Microservice optimisé pour les redirections à haut débit et à faible latence. Lit principalement à partir du cache, se rabat sur la base de données de métadonnées de liens. Publie les événements de clic vers une file d'attente de messages. * **Cache distribué (par ex. Redis Cluster) :** Stocke les correspondances `short_code` vers `long_url` fréquemment utilisées pour des redirections rapides. * **Base de données de métadonnées de liens (par ex. Cassandra/DynamoDB) :** Stocke toutes les métadonnées des URL courtes (short_code, long_url, expiration, statut, etc.). * **File d'attente de messages (par ex. Kafka/Kinesis) :** Ingestion des événements de clic bruts du service de redirection pour un traitement asynchrone. * **Processeur d'analyses :** Consomme les événements de clic bruts de la file d'attente de messages, effectue l'agrégation et les stocke dans la base de données d'analyses. * **Base de données d'analyses (par ex. ClickHouse/Redshift) :** Stocke les données de clic agrégées pour les requêtes. * **Data Lake (par ex. S3) :** Stocke les événements de clic bruts pour une rétention à long terme et une analyse plus approfondie. * **Service de détection d'abus :** S'intègre au service de raccourcissement pour analyser les nouvelles URL à la recherche de contenu malveillant. * **Surveillance et alertes :** Observabilité de tous les composants. **Flux de données :** * **Requête de raccourcissement :** Utilisateur -> API Gateway -> Service de raccourcissement -> Détection d'abus -> Base de données de métadonnées de liens (écriture) -> Cache (écriture). * **Requête de redirection :** Utilisateur -> CDN (optionnel) -> Load Balancer -> Service de redirection -> Cache (lecture) -> Base de données de métadonnées de liens (lecture de secours) -> File d'attente de messages (écriture d'événement de clic) -> Redirection vers l'URL longue. * **Traitement des analyses :** File d'attente de messages -> Processeur d'analyses -> Base de données d'analyses (écriture agrégée) / Data Lake (écriture brute). 2. Choix de stockage pour les métadonnées de liens, le chemin de redirection et les événements d'analyse, avec justification : * **Métadonnées de liens (URL courte -> URL longue, expiration, statut, etc.) :** * **Choix :** Base de données NoSQL distribuée mondialement (par ex. Apache Cassandra ou AWS DynamoDB Global Tables). * **Justification :** Gère un débit élevé de lecture/écriture (1,5 milliard de lectures/jour, 120 millions d'écritures/mois), offre un accès à faible latence depuis plusieurs régions, assure une haute disponibilité et évolue horizontalement. La clé primaire serait le `short_code` pour des recherches efficaces. * **Chemin de redirection (correspondance Short Code -> Long URL pour une recherche rapide) :** * **Choix :** Cache distribué en mémoire (par ex. Redis Cluster). * **Justification :** Crucial pour atteindre une latence p95 inférieure à 80 ms pour les redirections. Réduit considérablement la charge sur la base de données principale. Les liens fréquemment utilisés sont mis en cache de manière agressive avec des TTL appropriés (par ex. basés sur l'expiration du lien ou une politique LRU). Répliqué entre les régions pour un accès local. * **Événements d'analyse (clics bruts) :** * **Choix :** File d'attente de messages (par ex. Apache Kafka ou AWS Kinesis) pour l'ingestion, suivie d'un Data Lake (par ex. AWS S3) pour le stockage. * **Justification :** Kafka/Kinesis gère le volume d'écriture immense (1,5 milliard d'événements/jour) en découplant le chemin de redirection du traitement des analyses, garantissant que les redirections restent rapides. S3 offre un stockage rentable et hautement durable pour les événements bruts conservés pendant 90 jours, adapté au traitement par lots et à l'analyse historique. * **Analyses agrégées :** * **Choix :** Base de données analytique en colonnes (par ex. ClickHouse ou AWS Redshift). * **Justification :** Optimisée pour les requêtes analytiques complexes et les agrégations sur de grands ensembles de données. Permet des requêtes rapides sur les données agrégées (par ex. clics quotidiens, distribution des navigateurs) en moins de 15 minutes, conservées pendant 2 ans, sans impacter la base de données opérationnelle. 3. Génération de short-code, y compris comment éviter les collisions et gérer les alias personnalisés : * **Stratégie de génération de short-code :** 1. **Génération d'ID distribuée :** Utiliser un générateur d'ID unique et distribué (par ex. un service personnalisé générant des ID de type Snowflake ou UUID v7) pour produire un entier de 64 bits unique et monotone à l'échelle mondiale. 2. **Encodage Base62 :** Encoder cet entier unique en une chaîne Base62 compacte (0-9, a-z, A-Z). Un ID de 64 bits peut produire un code court de 6 à 10 caractères, offrant un vaste espace de noms (par ex. 6 caractères fournissent 62^6 ≈ 56 milliards de codes uniques, suffisant pour 120 millions/mois pendant de nombreuses années). * **Évitement des collisions :** * **Basé sur l'ID :** Étant donné que l'ID sous-jacent est garanti unique, le short-code encodé en Base62 sera également unique, évitant ainsi intrinsèquement les collisions pour les codes générés par le système. * **Solution de repli aléatoire (pour la robustesse) :** Comme option secondaire ou pour des cas d'utilisation spécifiques, un générateur de chaînes aléatoires pourrait être utilisé. Dans ce cas, générer un short-code candidat, puis effectuer une recherche rapide dans la base de données de métadonnées de liens et le cache. Si une collision est détectée, régénérer et réessayer plusieurs fois. C'est moins efficace mais offre une solution de repli. * **Alias personnalisés :** 1. **Soumission par l'utilisateur :** L'utilisateur soumet son `custom_alias` souhaité avec l'`long_url`. 2. **Validation :** Le service de raccourcissement valide le `custom_alias` (par ex. longueur, caractères autorisés, pas un mot réservé, pas mis sur liste noire). 3. **Vérification d'unicité :** Avant la création, le service de raccourcissement effectue une recherche dans la base de données de métadonnées de liens pour vérifier si le `custom_alias` existe déjà. Cette vérification doit être fortement cohérente. 4. **Réservation :** Si le `custom_alias` est disponible, il est stocké directement comme `short_code` dans la base de données de métadonnées de liens. S'il n'est pas disponible, la requête est rejetée, invitant l'utilisateur à en choisir un autre. 4. Plan de mise à l'échelle pour le trafic mondial, y compris la mise en cache, le partitionnement/sharding et les considérations multi-régions : * **Mise en cache :** * **CDN :** Utiliser un réseau de diffusion de contenu (CDN) pour les actifs statiques et potentiellement pour la résolution DNS des liens courts, dirigeant les utilisateurs vers le point d'accès le plus proche. * **Cache distribué (Redis Cluster) :** Déployer des clusters Redis dans chaque région géographique majeure. Ces clusters stockeront les correspondances `short_code` vers `long_url` les plus fréquemment consultées. Les entrées du cache ont des TTL alignés sur l'expiration du lien ou une politique LRU. Cela décharge considérablement la base de données pour les 1,5 milliard de redirections quotidiennes. * **Partitionnement/Sharding :** * **Base de données de métadonnées de liens :** Partitionner la base de données par `short_code` (par ex. en utilisant un hachage du short code). Cela distribue les données et la charge des requêtes sur plusieurs nœuds de base de données. Chaque partition est répliquée pour une haute disponibilité au sein d'une région. * **Base de données d'analyses :** Partitionner les événements de clic bruts par temps (par ex. partitions quotidiennes ou horaires) et les données agrégées par `short_code` et `date` pour optimiser les performances des requêtes et les politiques de rétention des données. * **Considérations multi-régions :** * **Actif-Actif pour les redirections :** Déployer le service de redirection, le cache distribué et la base de données de métadonnées de liens (avec réplication mondiale) dans plusieurs régions géographiques (par ex. Amérique du Nord, Europe, Asie-Pacifique). Geo-DNS dirige les utilisateurs vers la région la plus proche, garantissant des redirections à faible latence dans le monde entier. * **Actif-Passif/Actif-Actif pour le service de raccourcissement :** Le service de raccourcissement peut être déployé en actif-passif (primaire dans une région, répliques dans d'autres) ou en actif-actif, en fonction des exigences de cohérence des écritures et de la complexité. Les écritures sont moins fréquentes que les lectures, donc une latence légèrement plus élevée pour la création est acceptable si cela simplifie la cohérence. * **Réplication de base de données mondiale :** La base de données de métadonnées de liens (par ex. tables globales DynamoDB ou réplication multi-centres de données de Cassandra) garantit que les données sont répliquées entre les régions, permettant des lectures locales pour les redirections et offrant des capacités de reprise après sinistre. * **Ingestion des analyses :** Les files d'attente de messages régionales (Kafka/Kinesis) agrègent les événements de clic localement, qui sont ensuite transmis à un Data Lake/base de données d'analyses central ou répliqués entre les régions pour une analyse consolidée. 5. Plan de fiabilité couvrant les pannes, les clés chaudes, la reprise après sinistre et le comportement en mode dégradé : * **Pannes :** * **Redondance :** Tous les services (raccourcissement, redirection, processeurs d'analyses) sont déployés avec une redondance N+1 dans plusieurs zones de disponibilité au sein de chaque région, derrière des équilibreurs de charge. * **Réplication de base de données :** La base de données de métadonnées de liens et la base de données d'analyses utilisent la réplication synchrone/asynchrone entre les zones de disponibilité et les régions pour garantir la durabilité et la disponibilité des données. * **Disjoncteurs et tentatives :** Implémenter des disjoncteurs et des mécanismes de tentatives avec backoff exponentiel dans les microservices pour éviter les défaillances en cascade et gérer gracieusement les problèmes transitoires. * **Surveillance et alertes :** Surveillance complète de l'état du système, des métriques de performance et des taux d'erreur avec des alertes automatisées pour les problèmes critiques. * **Clés chaudes :** * **Sharding du cache :** Le cache distribué (Redis Cluster) est shardé, distribuant les clés chaudes sur plusieurs nœuds pour éviter qu'un seul nœud ne devienne un goulot d'étranglement. * **Réchauffement du cache :** Pour les liens fréquemment consultés anticipés (par ex. lors de campagnes majeures), les précharger dans le cache. * **Limitation de débit :** Implémenter une limitation de débit au niveau de l'API Gateway et du service de redirection pour protéger les systèmes backend contre les pics de trafic soudains ou les abus ciblant des liens spécifiques. * **Reprise après sinistre :** * **Actif-Actif multi-régions :** Le déploiement actif-actif du service de redirection et la base de données de métadonnées de liens répliquée mondialement offrent une reprise après sinistre inhérente pour les redirections. Si une région tombe en panne, le trafic est automatiquement redirigé vers une autre région saine via Geo-DNS. * **Sauvegardes de données :** Sauvegardes régulières et automatisées de toutes les bases de données critiques (métadonnées de liens, analyses agrégées) vers un stockage durable géographiquement séparé (par ex. S3). * **Playbooks de récupération :** Procédures documentées et régulièrement testées pour le basculement, la restauration des données et la récupération complète du système. * **Comportement en mode dégradé :** * **Dégradation des analyses :** Si la file d'attente de messages ou le processeur d'analyses rencontre des problèmes, les événements de clic bruts peuvent être temporairement mis en mémoire tampon ou, dans les cas extrêmes, abandonnés (avec alertes). Les redirections doivent continuer à fonctionner sans interruption. * **Échecs/erreurs de cache :** Si le cache distribué tombe en panne ou connaît une latence élevée, le service de redirection se rabat sur l'interrogation de la base de données de métadonnées de liens. Cela entraînera une latence de redirection plus élevée mais garantira la continuité du service. Les disjoncteurs empêchent de surcharger la base de données. * **Dégradation du service de raccourcissement :** Si le service de raccourcissement est défaillant, les redirections ne sont pas affectées. Les utilisateurs pourraient connaître un ralentissement de la création de liens ou une indisponibilité temporaire de l'API de création, mais les liens existants continueront de fonctionner. 6. API clés et modèles de données principaux : * **API clés :** * **`POST /api/v1/shorten`** * **Description :** Crée une nouvelle URL courte. * **Corps de la requête :** `{"long_url": "string", "custom_alias": "string (optionnel)", "expiration_date": "timestamp ISO 8601 (optionnel)", "user_id": "string (optionnel)"}` * **Réponse :** `{"short_url": "string", "long_url": "string", "expires_at": "timestamp ISO 8601 (optionnel)"}` * **`GET /{short_code}`** * **Description :** Redirige vers l'URL longue d'origine. * **Réponse :** Redirection HTTP 301/302 vers `long_url`. * **`GET /api/v1/links/{short_code}/analytics`** * **Description :** Récupère les analyses de clics pour une URL courte spécifique. * **Réponse :** `{"short_code": "string", "total_clicks": "integer", "daily_clicks": [{"date": "YYYY-MM-DD", "count": "integer"}], "browser_distribution": {"Chrome": 100, "Firefox": 50}, "country_distribution": {"US": 70, "DE": 30}}` * **`PUT /api/v1/links/{short_code}/status`** * **Description :** Met à jour le statut d'une URL courte (par ex. désactiver). * **Corps de la requête :** `{"status": "enum (active, disabled)"}` * **Réponse :** `{"short_code": "string", "status": "string"}` * **Modèles de données principaux :** * **Métadonnées de liens (stockées dans la base de données de métadonnées de liens) :** ``` { "short_code": "string (Clé primaire)", "long_url": "string", "user_id": "string (Clé étrangère, optionnel)", "created_at": "timestamp", "expires_at": "timestamp (optionnel)", "status": "enum (active, disabled, expired)", "is_custom_alias": "boolean", "last_accessed_at": "timestamp (pour LRU/nettoyage)" } ``` * **Événement de clic (brut - stocké dans le Data Lake, ingéré via la file d'attente de messages) :** ``` { "event_id": "UUID (Clé primaire)", "short_code": "string", "timestamp": "timestamp", "ip_address_hash": "string (anonymisé/haché)", "user_agent": "string", "referrer": "string (optionnel)", "country": "string (dérivé de l'IP)", "city": "string (dérivé de l'IP)" } ``` * **Analyses agrégées (stockées dans la base de données d'analyses) :** ``` { "short_code": "string (Clé de partition)", "date": "date (Clé de tri)", "total_clicks": "integer", "browser_counts": "map<string, integer>", "os_counts": "map<string, integer>", "country_counts": "map<string, integer>", "referrer_counts": "map<string, integer>" } ``` 7. Considérations sur la prévention des abus et la sécurité : * **Détection de liens malveillants :** * **Mise sur liste noire :** Maintenir une liste noire continuellement mise à jour des domaines malveillants connus, des sites de phishing et des URL de spam. Les nouvelles soumissions de `long_url` sont vérifiées par rapport à cette liste. * **Analyse en temps réel :** S'intégrer aux API tierces de navigation sécurisée (par ex. Google Safe Browsing API, VirusTotal) lors du processus de création de lien pour analyser le `long_url` à la recherche de menaces connues. * **Heuristiques :** Implémenter des algorithmes pour détecter les modèles d'URL suspects, les redirections excessives ou les mots-clés couramment associés aux abus. * **Prévention du spam et des abus :** * **Limitation de débit :** Appliquer une limitation de débit stricte sur l'API `POST /shorten` par adresse IP et/ou utilisateur authentifié pour empêcher le spam automatisé. * **CAPTCHA/reCAPTCHA :** Pour la création de liens anonymes, implémenter des défis CAPTCHA pour dissuader les bots. * **Comptes utilisateurs :** Exiger l'authentification de l'utilisateur pour les alias personnalisés, des limites de création plus élevées et l'accès aux analyses. Cela assure la responsabilité. * **Mécanisme de signalement :** Fournir un moyen clair aux utilisateurs de signaler les liens courts abusifs. Les liens signalés sont examinés et désactivés s'ils sont jugés malveillants. * **Désactivation de liens :** Permettre aux utilisateurs de désactiver manuellement leurs propres liens. Le système peut également désactiver automatiquement les liens signalés par la détection d'abus ou signalés par d'autres. * **Considérations de sécurité :** * **HTTPS partout :** Imposer HTTPS pour tous les points d'accès API et les redirections afin d'assurer le chiffrement des données en transit. * **Validation et assainissement des entrées :** Valider et assainir rigoureusement toutes les entrées fournies par l'utilisateur (`long_url`, `custom_alias`) pour empêcher les vulnérabilités web courantes telles que XSS, injection SQL et traversée de répertoire. * **Contrôle d'accès :** Implémenter le contrôle d'accès basé sur les rôles (RBAC) pour les outils de gestion internes et les fonctionnalités de gestion de liens spécifiques à l'utilisateur. * **Anonymisation des données :** Anonymiser ou hacher les adresses IP et autres informations personnellement identifiables (PII) dans les données d'analyse de clics pour se conformer aux réglementations sur la confidentialité (par ex. GDPR, CCPA). * **Audits de sécurité réguliers :** Effectuer des audits de sécurité périodiques, des tests d'intrusion et des analyses de vulnérabilités pour identifier et corriger les faiblesses potentielles. * **Protection DDoS :** Utiliser les services d'atténuation DDoS des fournisseurs de cloud (par ex. AWS Shield, Cloudflare) en périphérie. 8. Les principaux compromis que vous avez faits et pourquoi : * **Cohérence vs Disponibilité/Latence pour les redirections :** * **Compromis :** Priorité à une disponibilité et une latence extrêmes pour les redirections par rapport à une forte cohérence pour les métadonnées de liens. Bien que la création de liens nécessite une forte cohérence pour l'unicité des alias, un lien nouvellement créé ou mis à jour peut prendre quelques millisecondes pour se propager à tous les caches et répliques de base de données mondiales avant d'être disponible de manière cohérente pour les redirections. * **Pourquoi :** Les redirections sont l'opération la plus critique et la plus volumineuse. Un léger retard dans la redirection globale d'un nouveau lien est acceptable, tandis que toute latence ou temps d'arrêt significatif pour les redirections aurait un impact sévère sur l'expérience utilisateur et les objectifs de fiabilité du service. * **Coût vs Performance/Scalabilité :** * **Compromis :** Choix d'une architecture multi-régions, répliquée mondialement avec une mise en cache étendue et des bases de données spécialisées, ce qui entraîne intrinsèquement des coûts d'infrastructure plus élevés par rapport à une configuration simple dans une seule région. * **Pourquoi :** Les hypothèses d'échelle (1,5 milliard de redirections/jour, distribution mondiale) et les objectifs de performance (p95 < 80 ms) nécessitent ce niveau d'infrastructure distribuée. Des services cloud courants et des composants open-source (comme Kafka, Redis) ont été choisis lorsque possible pour optimiser les coûts tout en répondant aux exigences de performance et d'évolutivité. * **Granularité des données vs Coût de stockage/Performance des requêtes pour les analyses :** * **Compromis :** Conserver les événements de clic bruts pendant une période plus courte (90 jours) dans un data lake rentable et stocker les données agrégées pendant une période plus longue (2 ans) dans une base de données d'analyses plus performante, mais potentiellement plus coûteuse. * **Pourquoi :** Stocker 1,5 milliard d'événements bruts par jour pendant 2 ans serait prohibitif en termes de coûts et lent pour les requêtes en temps réel. Cette approche équilibre le besoin d'analyses historiques détaillées (via les données brutes dans S3) avec l'exigence d'informations agrégées rapides (via la base de données d'analyses) dans les limites du budget. * **Longueur du short code vs Probabilité de collision/Devinabilité :** * **Compromis :** Choix de l'encodage Base62 pour des short codes compacts (par ex. 6-10 caractères). Bien qu'un code aléatoire de 6 caractères ait un risque théorique de collision, la stratégie de génération basée sur l'ID élimine ce risque pour les codes générés par le système. Pour les alias personnalisés, la détection de collision est explicite. * **Pourquoi :** La compacité est une caractéristique essentielle d'un raccourcisseur d'URL. La stratégie choisie fournit un espace de noms suffisamment vaste pour éviter les collisions pratiques pour les codes générés par le système et gère les collisions d'alias personnalisés avec élégance, sans nécessiter de short codes excessivement longs ou complexes qui iraient à l'encontre de l'objectif de raccourcissement. * **Complexité vs Ensemble de fonctionnalités :** * **Compromis :** Concentration sur un système de base robuste pour le raccourcissement, la redirection et les analyses de base, en acceptant que des fonctionnalités plus avancées (par ex. tests A/B, gestion utilisateur complexe, rapports complexes) seraient des ajouts itératifs. * **Pourquoi :** Pour répondre aux objectifs agressifs de performance et de disponibilité de la fonctionnalité principale dans une portée de conception raisonnable. L'ajout de trop de fonctionnalités initialement augmenterait la complexité, les points de défaillance potentiels et le temps de développement, compromettant potentiellement la stabilité du service principal.

CONCEPTION : SERVICE GLOBAL DE RACCOURCISSEMENT D'URL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. ARCHITECTURE DE HAUT NIVEAU ET FLUX DE DONNÉES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPOSANTS [Client] │ ▼ [DNS Anycast Global / GeoDNS] │ ▼ [PoPs Périphériques Régionaux — CDN / Proxy inverse Nginx] │ (cache hit → réponse immédiate 301/302) │ (cache miss → transfert vers l'origine) ▼ [Passerelle API Régionale (limitation de débit, authentification, terminaison TLS)] │ ├──► [Service de Redirection] ──► [Cluster Redis (cache de clés chaudes)] │ │ miss │ ▼ │ [Magasin de Métadonnées de Liens (Cassandra)] │ └──► [Service de Création] ──► [Générateur d'ID (style Snowflake)] │ │ ├──► [Magasin de Métadonnées de Liens (Cassandra)] └──► [Vérificateur d'Alias Personnalisé (SET Redis + Cassandra)] [Service de Redirection] ──► [Éditeur d'Événements de Clics (Kafka)] │ ▼ [Processeur de Flux (Flink / Spark Streaming)] │ ┌───────────┴────────────┐ ▼ ▼ [Magasin d'Événements Bruts [Magasin d'Analyses (S3 + Parquet, 90j)] Agrégées (ClickHouse, 2a)] FLUX DE DONNÉES — REDIRECTION (CHEMIN CRITIQUE) 1. L'utilisateur visite https://sho.rt/aB3xYz 2. GeoDNS redirige vers le PoP régional le plus proche. 3. Le CDN Edge vérifie son cache local pour la clé "aB3xYz". - HIT : renvoie HTTP 301 (mettable en cache) ou 302 (non mettable en cache pour l'analyse) immédiatement. Déclenche une balise asynchrone vers le pipeline d'analyse. - MISS : transfère vers le Service de Redirection régional. 4. Le Service de Redirection vérifie le cluster Redis régional. - HIT : renvoie l'URL de destination, déclenche un événement Kafka, répond 302. - MISS : lit depuis Cassandra (réplique la plus proche), remplit Redis, répond 302. 5. Le consommateur Kafka (Flink) traite l'événement de clic en quelques secondes ; les agrégations arrivent dans ClickHouse en environ 5 minutes ; au pire en 15 minutes. FLUX DE DONNÉES — CRÉATION 1. Le client envoie une requête POST au Service de Création via la passerelle API. 2. Vérifications de limitation de débit et d'authentification appliquées. 3. Si alias personnalisé : vérifier le SET Redis et Cassandra pour collision ; rejeter si pris. 4. Si généré automatiquement : ID Snowflake → encodage Base62 → code à 7 caractères. 5. Écrire dans Cassandra (écriture en quorum, RF=3). 6. Optionnellement, préchauffer le cache Redis immédiatement. 7. Renvoyer l'URL courte au client. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. CHOIX DE STOCKAGE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MAGASIN DE MÉTADÉES DE LIENS — Apache Cassandra Justification : - 120M de nouveaux liens/mois ≈ 46 liens/sec en moyenne, avec des pics de 10 à 20 fois. Cassandra gère un débit d'écriture élevé avec une cohérence réglable. - Le modèle d'accès principal est la recherche par clé unique par short_code — le modèle de clé de partition de Cassandra est idéal. - Réplication multi-centres de données (RF=3 par région, 3 régions) offre une disponibilité de 99,99 %+ sans point de défaillance unique. - Mise à l'échelle horizontale ; aucune transaction inter-partitions coûteuse nécessaire. - Le support TTL est natif — les liens expirés sont automatiquement marqués comme supprimés. - Coût : nœuds standards, pas de frais de licence. Schéma (simplifié) : Table : links short_code TEXT CLÉ PRIMAIRE long_url TEXT owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nullable ; TTL Cassandra défini sur la ligne) is_disabled BOOLEAN is_custom BOOLEAN Alternative considérée : DynamoDB — bon mais dépendance vis-à-vis du fournisseur et coût à cette échelle ; PostgreSQL — pas de mise à l'échelle horizontale pour ce volume d'écriture sans complexité de partitionnement significative. CACHE DE CHEMIN DE REDIRECTION — Cluster Redis (par région) - Stocke short_code → {long_url, is_disabled, expires_at} sous forme de hash. - TTL sur l'entrée du cache = min(expiration du lien, 24 heures) pour éviter les entrées obsolètes. - Mode cluster avec 6 nœuds (3 primaires + 3 répliques) par région ; ~50 Go de RAM par région couvrent l'ensemble de travail actif (environ 10M liens les plus consultés). - Politique d'éviction : allkeys-lru. - Coût justifié : taux de succès Redis attendu >95% ; chaque échec de cache coûte une lecture Cassandra (~5–10 ms) plus la latence ; à 17 000 redirections/sec par région, éviter les lectures Cassandra est essentiel pour l'objectif p95. ANALYSE — ÉVÉNEMENTS BRUTS : Apache Kafka + S3 (Parquet) - Kafka (cluster à 3 brokers par région, sujet : click_events, 64 partitions) met en mémoire tampon les événements de clic de manière durable. - Les consommateurs Flink lisent depuis Kafka, enrichissent les événements (géolocalisation IP, analyse de l'agent utilisateur) et écrivent des fichiers Parquet sur S3 toutes les 5 minutes. - La politique de cycle de vie S3 supprime les fichiers bruts après 90 jours. - Coût : S3 est bon marché (~0,023 $/Go/mois) ; 1,5 milliard d'événements/jour × ~200 octets ≈ 300 Go/jour → ~27 To/90 jours → ~620 $/mois de stockage. ANALYSE — AGRÉGÉE : ClickHouse - Flink écrit également des lignes pré-agrégées (par short_code, par heure, par pays/appareil) dans ClickHouse. - Le stockage en colonnes et l'exécution vectorisée de ClickHouse rendent les requêtes d'agrégation de séries temporelles rapides. - Facteur de réplication 2 par région ; rétention de 2 ans. - Taille estimée : ~1 To/an agrégé → très gérable. - Alternative considérée : Apache Druid — également excellent mais plus lourd opérationnellement ; ClickHouse est plus simple pour ce cas d'utilisation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. STRATÉGIE DE GÉNÉRATION DE CODES COURTS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CODES GÉNÉRÉS AUTOMATIQUEMENT Stratégie : ID distribué de style Snowflake → encodage Base62 1. Chaque instance du Service de Création détient un ID d'Worker unique (attribué au démarrage via ZooKeeper ou une simple table de base de données). 2. Générer un ID Snowflake de 64 bits : [horodatage 41 bits ms | ID d'Worker 10 bits | séquence 12 bits]. 3. Encoder l'ID en Base62 (caractères : 0-9, a-z, A-Z). 4. Un entier de 64 bits qu'il encode en 11 caractères Base62 au maximum ; en pratique, pour les ID générés au cours des ~10 premières années, 7 à 8 caractères suffisent. 5. 7 caractères en Base62 = 62^7 ≈ 3,5 billions de combinaisons — dépasse largement 120M/mois × 12 mois × 10 ans = ~14,4 milliards de liens. Évitement des collisions : - Les ID Snowflake sont globalement uniques par construction (ID d'Worker + horodatage + séquence). Aucune collision n'est possible à moins que deux Workers ne partagent le même ID d'Worker, ce qui est évité par le service de coordination. - Pas besoin de boucle "vérifier puis insérer" pour les codes générés automatiquement. Devinabilité : - Les ID Snowflake séquentiels encodés en Base62 ne sont pas aléatoires mais ne sont pas non plus trivialement énumérables (le composant horodatage change chaque milliseconde, la séquence se réinitialise). Pour plus d'obscurité, effectuez un XOR des 32 bits inférieurs avec un secret par déploiement avant l'encodage. Ce n'est pas une sécurité cryptographique mais cela augmente la barre pour les attaques par énumération. - Si une imprévisibilité plus forte est nécessaire : générer 6 octets aléatoires → Base62 → code à 8 caractères ; vérifier dans Cassandra la collision (rare à cette échelle) ; réessayer en cas de collision. Taux de collision attendu à 1,4 milliard de liens existants sur un espace de 62^8 ≈ 218 billions est négligeable (<0,001%). ALIAS PERSONNALISÉS 1. L'utilisateur fournit l'alias souhaité (par exemple, "ma-promo-2025"). 2. Valider : 3 à 50 caractères, alphanumériques + tirets, pas de mots réservés (api, admin, health, etc.). 3. Vérifier dans le SET Redis "custom_aliases" l'existence (vérification de type filtre anti-bloom O(1), ou un SET Redis). 4. Tenter une insertion Cassandra SI NON EXISTANT (transaction légère / comparer et définir). 5. Si déjà pris, renvoyer HTTP 409 Conflict. 6. Les alias personnalisés sont stockés avec is_custom=true ; ils ne sont jamais écrasés par le chemin de génération automatique. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. PLAN DE MISE À L'ÉCHELLE POUR LE TRAFIC MONDIAL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MATHÉMATIQUES DU TRAFIC - 1,5 milliard de redirections/jour = ~17 400 requêtes/sec en moyenne ; supposer 3× pic = ~52 000 requêtes/sec. - 120 millions de créations/mois = ~46/sec en moyenne ; 10× pic = ~460/sec. La création n'est pas le goulot d'étranglement. COUCHE DE MISE EN CACHE Couche 1 — CDN/Edge (Cloudflare, Fastly, ou Nginx auto-hébergé dans les PoPs) : - Mettre en cache les réponses 301 pour les liens non expirables et non critiques pour l'analyse. Cache-Control: max-age=3600. - Utiliser 302 pour les liens où les analyses par clic sont requises (la plupart des liens) ; ceux-ci contournent le cache CDN mais bénéficient toujours de la proximité géographique. - Taux de succès CDN estimé pour les liens populaires : 40–60 % du trafic servi en périphérie sans atteindre l'origine. Couche 2 — Cluster Redis Régional : - Couvre les ~40–60 % restants des requêtes qui atteignent l'origine. - Taux de succès Redis attendu : >95 % des requêtes atteignant l'origine. - Lectures Cassandra nettes : <5 % de 17 400 requêtes/sec ≈ ~870 requêtes/sec — bien dans la capacité de Cassandra. PARTITIONNEMENT / SHARDING Cassandra : - Clé de partition = short_code. Le hachage cohérent de Cassandra distribue les partitions uniformément sur les nœuds. - Pas de sharding manuel nécessaire ; ajouter des nœuds pour rééquilibrer automatiquement. - Éviter les points chauds : short_code a une haute cardinalité ; aucune partition unique ne sera démesurément grande. Redis : - Redis Cluster utilise des slots de hachage (16 384 slots) distribués sur les nœuds. Les hachages de short_code sont mappés uniformément. - Les clés chaudes (liens viraux) sont traitées séparément — voir section Fiabilité. Kafka : - 64 partitions par sujet ; clé de partition = short_code. Assure un traitement ordonné par lien tout en parallélisant entre les consommateurs. DÉPLOIEMENT MULTI-RÉGION Régions : US-East, EU-West, AP-Southeast (minimum 3 pour une disponibilité de 99,99 %). Cassandra : - Réplication multi-centres de données : RF=3 par centre de données, 3 centres de données. - Écritures : LOCAL_QUORUM (2 des 3 nœuds dans le DC local) pour la création — rapide et cohérente au sein de la région. - Lectures : LOCAL_QUORUM pour la redirection — lit depuis le DC le plus proche. - La réplication inter-DC est asynchrone ; la cohérence éventuelle entre les régions est acceptable pour les redirections (un lien nouvellement créé peut prendre moins de 1 seconde à se propager globalement — acceptable). Redis : - Cluster indépendant par région ; pas de réplication inter-régions (coût et complexité non justifiés). - Un échec de cache se rabat sur la réplique Cassandra locale. DNS : - GeoDNS redirige les utilisateurs vers la passerelle API régionale la plus proche. - IP Anycast pour le domaine de redirection assure un routage à latence la plus faible. Service de Création : - Sans état ; déployer dans chaque région. Les ID d'Worker sont globalement uniques (coordonnés via un ZooKeeper global léger ou une simple table de base de données avec préfixe de région). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5. PLAN DE FIABILITÉ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SCÉNARIOS DE DÉFAILLANCE ET ATTÉNUATIONS Défaillance d'un nœud Redis : - Redis Cluster promeut automatiquement une réplique (généralement <30 secondes). - Pendant le basculement, les requêtes se rabattent sur Cassandra. Cassandra peut gérer la rafale (~870 req/sec normalement ; rafale à ~17 000 req/sec pendant <30 secondes est gérable avec un provisionnement approprié — dimensionner Cassandra pour 2× la charge de lecture de pointe attendue). - Disjoncteur dans le Service de Redirection : si Redis est totalement indisponible, contourner le cache et lire directement depuis Cassandra. Défaillance d'un nœud Cassandra : - RF=3 avec LOCAL_QUORUM signifie qu'une défaillance de nœud est transparente ; 2 défaillances de nœuds dégradent à LOCAL_ONE (toujours fonctionnel, légèrement moins cohérent). - Le protocole de commérage de Cassandra détecte les défaillances en quelques secondes ; le transfert d'indices assure que les écritures ne sont pas perdues. Défaillance d'une région entière : - Les vérifications de santé GeoDNS détectent l'indisponibilité d'une région en 30–60 secondes et redirigent le trafic vers la région suivante la plus proche. - La réplication inter-DC de Cassandra garantit que les données sont disponibles dans les régions survivantes. - Objectif : RTO < 2 minutes, RPO = 0 pour les métadonnées de liens (écritures par quorum synchrones au sein du DC ; réplication inter-DC asynchrone signifie une perte de données potentielle de <1 seconde pour les créations très récentes — acceptable). CLÉS CHAUDES (LIENS VIRAUX) Problème : un seul code court viral pourrait générer des millions de requêtes/seconde, submergeant un slot Redis unique ou une partition Cassandra. Atténuations : 1. Cache local en mémoire dans chaque instance du Service de Redirection (par exemple, Caffeine, LRU 10 000 entrées, TTL de 30 secondes). Absorbe les requêtes répétées au sein d'un même pod sans atteindre Redis. 2. Réplication de clés Redis : pour les clés chaudes détectées (surveillées via Redis MONITOR ou un compteur à fenêtre glissante), répliquer la clé dans plusieurs slots Redis avec un suffixe (par exemple, aB3xYz:0, aB3xYz:1 ... aB3xYz:N) et en sélectionner une aléatoirement à la lecture. 3. Mise en cache CDN : pour les liens non analytiques, pousser les liens chauds vers le CDN avec un TTL court (60 secondes) pour absorber le trafic en périphérie. 4. Cassandra : les clés chaudes ne posent pas de problème car Redis absorbe >99 % des lectures pour les liens chauds. REPRISE APRÈS SINISTRE - Cassandra : instantanés quotidiens vers S3 (instantané nodetool). La réplication inter-régions fournit une reprise après sinistre en direct. - Redis : persistance Redis (AOF + RDB) sur disque local ; Redis est un cache — la perte est acceptable (se rabat sur Cassandra). Aucune réplication Redis inter-régions nécessaire. - Kafka : facteur de réplication 3 au sein de la région ; Kafka MirrorMaker 2 inter-régions réplique les événements de clic vers une région secondaire pour la reprise après sinistre des analyses. - ClickHouse : tables répliquées (ReplicatedMergeTree) ; sauvegardes quotidiennes vers S3. COMPORTEMENT EN MODE DÉGRADÉ - Si le pipeline d'analyse (Kafka/Flink) est en panne : les redirections continuent sans interruption. Les événements de clic sont mis en mémoire tampon dans Kafka (rétention de 7 jours) ; les analyses rattrapent lorsque le pipeline est rétabli. Le SLA pour les analyses (fraîcheur de 15 minutes) peut être temporairement violé — acceptable. - Si le Service de Création est en panne : les redirections existantes continuent de fonctionner (le chemin de lecture est indépendant). La création de nouveaux liens échoue gracieusement avec 503. - Si Cassandra est dégradé (quorum indisponible) : le Service de Redirection se rabat en mode Redis uniquement. Les liens non présents dans Redis renvoient 503 plutôt qu'une redirection incorrecte. C'est un mode dégradé de dernier recours. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6. API CLÉS ET MODÈLES DE DONNÉES DE BASE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ API REST POST /api/v1/links Requête : { "long_url": "https://example.com/very/long/path?q=1", "custom_alias": "ma-promo", // optionnel "expires_at": "2026-01-01T00:00:00Z", // ISO-8601 optionnel "owner_id": "uuid" // du jeton d'authentification } Réponse 201 : { "short_code": "aB3xYz", "short_url": "https://sho.rt/aB3xYz", "long_url": "https://example.com/very/long/path?q=1", "expires_at": "2026-01-01T00:00:00Z", "created_at": "2025-01-15T10:00:00Z" } Erreurs : 400 (URL invalide), 409 (alias pris), 422 (URL bloquée/malveillante), 429 (limitation de débit) GET /{short_code} Réponse 302: Location: <long_url> Réponse 301: Location: <long_url> (pour les liens mettables en cache, non analytiques) Réponse 404: lien non trouvé Réponse 410: lien expiré ou désactivé PATCH /api/v1/links/{short_code} Requête : { "is_disabled": true } // ou mettre à jour expires_at Réponse 200 : objet de lien mis à jour Auth : propriétaire uniquement DELETE /api/v1/links/{short_code} Réponse 204 Auth : propriétaire uniquement GET /api/v1/links/{short_code}/analytics Paramètres de requête : from, to, granularity (hour/day), group_by (country/device/referrer) Réponse 200 : { "short_code": "aB3xYz", "total_clicks": 142300, "series": [ { "timestamp": "2025-01-15T10:00:00Z", "clicks": 1200, "country": "US" }, ... ] } MODÈLES DE DONNÉES DE BASE links (Cassandra) short_code TEXT CLÉ PRIMAIRE long_url TEXT NON NULL owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nullable ; également défini comme TTL de ligne Cassandra) is_disabled BOOLEAN PAR DEFAUT false is_custom BOOLEAN PAR DEFAUT false abuse_flags INT DEFAULT 0 click_events (Kafka → S3 Parquet, brut) event_id UUID short_code TEXT timestamp TIMESTAMP ip_hash TEXT (SHA-256 de l'IP, pour la confidentialité) country_code TEXT (provenant de la géolocalisation IP) user_agent TEXT referrer TEXT region TEXT (région de service) analytics_hourly (ClickHouse, agrégé) short_code TEXT hour DateTime country_code TEXT device_type TEXT (mobile/desktop/bot) referrer_domain TEXT click_count UInt64 unique_ips UInt64 (approximation HyperLogLog) CLÉ PRIMAIRE (short_code, hour, country_code, device_type) ENGINE = ReplicatedMergeTree users (PostgreSQL — petite table, pas sur le chemin critique) user_id UUID CLÉ PRIMAIRE email TEXT UNIQUE api_key_hash TEXT rate_limit_tier TEXT created_at TIMESTAMP ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7. ATTÉNUATION DES ABUS ET SÉCURITÉ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DÉTECTION D'URL MALVEILLANTE 1. Vérification de l'API Safe Browsing au moment de la création : soumettre long_url à Google Safe Browsing (ou équivalent) avant de stocker. Rejeter avec 422 si signalé. Latence : ~50–100 ms, acceptable dans le SLA de création de 300 ms. 2. Liste noire de domaines : maintenir un SET Redis de domaines connus comme étant mauvais (hameçonnage, logiciels malveillants). Vérifier de manière synchrone à la création. Mis à jour toutes les heures à partir de flux d'intelligence sur les menaces. 3. Ré-analyse asynchrone : une tâche d'arrière-plan ré-analyse périodiquement les URL stockées par rapport aux listes noires mises à jour. Si une URL précédemment propre est plus tard signalée, définir is_disabled=true et abuse_flags=1. Le Service de Redirection vérifie is_disabled à chaque requête (depuis le cache). 4. Normalisation d'URL : analyser et normaliser les URL à la création pour éviter l'obscurcissement (par exemple, astuces d'encodage d'URL, attaques d'homographes sur les noms de domaine — vérifier les homographes IDN). LIMITATION DE DÉBIT - Limitation de débit par IP au niveau de la passerelle API : 10 créations/minute pour les utilisateurs anonymes, 100/minute pour les utilisateurs authentifiés, configurable par niveau. - Compteur à fenêtre glissante basé sur Redis (bucket de jetons) par IP/utilisateur. - Limitation de débit globale : 10 000 créations/seconde pour l'ensemble du système (bien au-dessus du pic attendu de 460/sec). - Chemin de redirection : pas de limitation de débit (public) ; protection DDoS via CDN (atténuation DDoS Cloudflare ou équivalent). PRÉVENTION DE L'ÉNUMÉRATION - Les codes courts ne sont pas purement séquentiels (obfuscation XOR Snowflake ou génération aléatoire). - Aucun point d'accès API pour lister tous les codes courts. - Les tentatives de redirection en masse non authentifiées (>1 000 codes uniques/minute depuis une IP) déclenchent un défi CAPTCHA ou un blocage temporaire de l'IP. AUTHENTIFICATION ET AUTORISATION - Clé API ou OAuth 2.0 JWT pour les points d'accès de création et de gestion. - PATCH/DELETE nécessitent une vérification de propriété (owner_id correspond au jeton). - API d'administration (point d'accès interne séparé) pour que l'équipe d'abus désactive les liens. CONFIDENTIALITÉ - Les adresses IP sont hachées (SHA-256 + sel par déploiement) avant d'être stockées dans les analyses. Les IP brutes ne sont jamais conservées. - RGPD : les utilisateurs peuvent demander la suppression de leurs liens et des analyses associées. Suppression Cassandra + étiquette de cycle de vie S3 pour les événements bruts. APPLICATION HTTPS - Toutes les URL courtes servies uniquement via HTTPS. Les requêtes HTTP sont redirigées vers HTTPS en périphérie. - En-tête HSTS sur le domaine court. PRÉVENTION DES REDIRECTIONS OUVERTES - Rediriger uniquement vers les URL qui ont été explicitement enregistrées. Aucune construction dynamique d'URL à partir des entrées utilisateur au moment de la redirection. - Valider le schéma long_url à la création : seuls http:// et https:// sont autorisés. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8. ARBITRAGES CLÉS ET JUSTIFICATIONS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ARBITRAGE 1 : 302 vs 301 pour les redirections - 301 (permanent) est mis en cache par les navigateurs indéfiniment → latence la plus faible, charge serveur nulle pour les visites répétées. Mais les analyses sont perdues (le navigateur n'appelle plus jamais le serveur), et désactiver/expirer un lien est impossible pour les clients mis en cache. - 302 (temporaire) atteint le serveur à chaque fois → analyses complètes, désactivation/expiration instantanée. Latence légèrement plus élevée pour les visites répétées. - Décision : Utiliser 302 par défaut pour tous les liens. Offrir 301 en option pour les utilisateurs qui souhaitent explicitement une mise en cache maximale et n'ont pas besoin d'analyses. C'est le défaut approprié pour un service qui vend des analyses. ARBITRAGE 2 : Cassandra vs base de données relationnelle pour les métadonnées de liens - Une base de données relationnelle (PostgreSQL) serait plus simple à exploiter et prendrait en charge des requêtes plus riches. Mais la mise à l'échelle horizontale pour 46 écritures/sec en moyenne (avec des pics de 10 à 20 fois) et 17 000 lectures/sec est douloureuse sans complexité de sharding significative. - Cassandra sacrifie la prise en charge de requêtes riches (pas de jointures, index secondaires limités) au profit d'une mise à l'échelle horizontale linéaire et d'une réplication multi-DC. Étant donné que la seule requête active est la recherche par clé unique par short_code, cet arbitrage est tout à fait acceptable. ARBITRAGE 3 : Cohérence éventuelle pour la propagation des liens inter-régions - Un lien créé dans US-East peut ne pas être immédiatement visible dans AP-Southeast (décalage de moins d'une seconde). Un utilisateur qui crée un lien et le partage immédiatement dans le monde entier pourrait voir un bref 404 dans les régions éloignées. - Alternative : écritures synchrones inter-régions (EACH_QUORUM) — garantit la cohérence globale mais ajoute 100–200 ms de latence à la création (viole le SLA de 300 ms dans des conditions défavorables) et réduit la disponibilité. - Décision : Accepter la cohérence éventuelle. La fenêtre de propagation de moins d'une seconde est un compromis UX acceptable. Le documenter. Le SLA de création est respecté. ARBITRAGE 4 : ID Snowflake vs codes aléatoires - Les ID Snowflake sont monotones croissants → légèrement prévisibles mais sans risque de collision, pas de vérification de base de données nécessaire, opérationnellement simple. - Codes aléatoires → meilleure imprévisibilité, mais nécessitent une vérification de collision (rare mais ajoute latence et complexité). - Décision : Snowflake + obfuscation XOR pour les codes générés automatiquement. Offre un bon équilibre entre simplicité, performance et imprévisibilité raisonnable. Codes aléatoires disponibles en option pour les cas d'utilisation sensibles à la sécurité. ARBITRAGE 5 : Pipeline d'analyse séparé vs écritures synchrones - Écrire les analyses de manière synchrone dans une base de données à chaque redirection ajouterait de la latence au chemin critique et créerait un goulot d'étranglement d'écriture à 17 000 req/sec. - Le pipeline Kafka asynchrone découple entièrement les analyses du chemin de redirection. Le coût est la cohérence éventuelle des analyses (jusqu'à 15 minutes) et une complexité opérationnelle accrue (Kafka + Flink + ClickHouse). - Décision : Pipeline asynchrone. L'exigence de fraîcheur des analyses de 15 minutes le permet explicitement. Le chemin de redirection doit être rapide ; les analyses peuvent prendre du retard. ARBITRAGE 6 : Portée de la mise en cache CDN - Mettre en cache toutes les redirections au niveau du CDN (301) donnerait des performances maximales mais casserait les analyses et la désactivation/expiration. - Mettre en cache uniquement les liens non analytiques et non expirables au niveau du CDN est un compromis. - Décision : Le CDN met en cache uniquement les liens explicitement marqués comme mettables en cache (option 301). Tous les autres utilisent 302 avec Cache-Control: no-store. C'est le défaut approprié pour un service où les analyses sont une fonctionnalité principale. ARBITRAGE 7 : ClickHouse vs Druid vs BigQuery pour les analyses - BigQuery : entièrement géré, sans opérations, mais latence de requête élevée (secondes) et coût à ce volume d'événements. - Druid : excellent pour les analyses en temps réel mais complexe opérationnellement (nœuds ZooKeeper, Broker, Historical, MiddleManager). - ClickHouse : plus simple à exploiter que Druid, excellentes performances de requête, rentable sur du matériel standard, bonne intégration Kafka. - Décision : ClickHouse. Meilleur équilibre entre simplicité opérationnelle, performance et coût pour ce cas d'utilisation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ RÉSUMÉ DE LA CAPACITÉ (DÉPLOIEMENT 3 RÉGIONS) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Service de Redirection : ~30 pods × 3 régions (auto-scalés, sans état) Service de Création : ~5 pods × 3 régions Cassandra : 9 nœuds × 3 régions (RF=3 par DC), ~2 To SSD chacun Cluster Redis : 6 nœuds × 3 régions, 50 Go RAM chacun Kafka : 3 brokers × 3 régions Flink : 10 gestionnaires de tâches × 3 régions ClickHouse : 4 nœuds × 3 régions (répliqués) S3 : ~27 To d'événements bruts/90 jours + ~3 To agrégés/2 ans Coût mensuel estimé de l'infrastructure : 15 000 $–25 000 $ (VM cloud standards), dominé par le stockage Cassandra et la mémoire Redis. La sortie CDN est le coût variable le plus important à grande échelle.