Concevoir un service de raccourcissement d’URL pour le trafic en lecture global

## Conception d'un service de raccourcissement d'URL ### 1. Architecture de haut niveau et composants principaux Le système sera composé de plusieurs microservices, déployés sur plusieurs zones de disponibilité et régions pour une haute disponibilité et une faible latence. * **API Gateway :** Gère les requêtes entrantes, l'authentification, la limitation de débit et achemine les requêtes vers les services appropriés. * **Service de création de liens :** Responsable de la génération des URL courtes, de leur stockage et de la gestion des alias personnalisés. Il interagit avec le service de génération d'ID et la base de données de métadonnées. * **Service de résolution de liens :** Gère les requêtes de redirection entrantes. Il récupère l'URL longue du cache ou de la base de données et effectue la redirection. Il enregistre également les événements de clic. * **Service d'analyse :** Traite les journaux de clics, agrège les données et fournit des rapports d'analyse. * **Service de génération d'ID :** Génère des ID courts uniques pour les URL. Il peut s'agir d'un service séparé et hautement disponible. * **Service de journalisation des clics :** Un service à haut débit responsable de l'ingestion des événements de clic bruts. * **Interface utilisateur Web/Panneau d'administration :** Permet aux utilisateurs de créer des liens, de les gérer et de visualiser les analyses. **Diagramme d'architecture (conceptuel) :** ``` +-----------------+ +-----------------+ +-----------------------+ | Load Balancer |----->| API Gateway |----->| Link Creation Service | +-----------------+ +-----------------+ +-----------------------+ | | | (Redirections) v +-----------------+ +-----------------+ +-----------------------+ | Load Balancer |----->| Link Resolution | +-----------------+ | Service | +-----------------+ | | | (Événements de clic) v +-----------------------+ | Click Logging Service | +-----------------------+ | | | (Logs bruts) v +-----------------------+ | Message Queue | +-----------------------+ | | | (Données traitées) v +-----------------------+ | Analytics Service | +-----------------------+ | | | (Données d'analyse) v +-----------------------+ | Analytics Database | +-----------------------+ **Bases de données :** * **Base de données de métadonnées :** Stocke les correspondances URL courte vers URL longue, les alias personnalisés, les horodatages de création, les heures d'expiration et les informations utilisateur. * **Base de données d'analyse :** Stocke les données de clics agrégées par lien. * **Service/Base de données de génération d'ID :** Pour générer des ID uniques. **Mise en cache :** * **Cache de lecture :** Pour les URL courtes fréquemment consultées afin d'accélérer les redirections. **File d'attente/Flux de messages :** * Pour découpler la journalisation des clics du chemin de redirection et permettre le traitement asynchrone pour l'analyse. ### 2. Modèle de données principal et choix de stockage **Base de données de métadonnées :** * **Choix :** Une base de données NoSQL distribuée comme Cassandra ou une base de données relationnelle fragmentée (par exemple, PostgreSQL avec Citus) pour la scalabilité et la disponibilité. * **Schéma :** * Table/collection `links` : * `short_id` (chaîne, clé primaire) : L'identifiant court unique. * `long_url` (chaîne) : L'URL longue d'origine. * `user_id` (chaîne, facultatif) : Identifiant de l'utilisateur qui a créé le lien. * `created_at` (horodatage) : Quand le lien a été créé. * `expires_at` (horodatage, facultatif) : Quand le lien expire. * `custom_alias` (chaîne, facultatif, index unique) : Alias défini par l'utilisateur. * `updated_at` (horodatage, facultatif) : Heure de la dernière mise à jour (pour la fenêtre de mise à jour de 10 minutes). * `destination_updated_at` (horodatage, facultatif) : Horodatage de la dernière mise à jour de l'URL de destination. **Base de données d'analyse :** * **Choix :** Une base de données de séries temporelles (par exemple, InfluxDB, TimescaleDB) ou un entrepôt de données (par exemple, Snowflake, BigQuery) pour une agrégation et une requête efficaces des données basées sur le temps. * **Schéma :** * Table/collection `click_analytics` : * `short_id` (chaîne, indexé). * `timestamp` (horodatage, indexé). * `country_code` (chaîne, facultatif). * `device_type` (chaîne, facultatif). * `aggregated_count` (entier) : Pour les données pré-agrégées. **Génération d'ID :** * **Choix :** Un service dédié de génération d'ID distribué (par exemple, utilisant l'algorithme Snowflake ou une séquence de base de données avec un service dédié). Cela garantit l'unicité et une haute disponibilité. **Journaux de clics :** * **Choix :** Une file d'attente de messages à haut débit (par exemple, Kafka, AWS Kinesis) pour mettre en mémoire tampon les événements de clic bruts avant qu'ils ne soient traités par le service d'analyse. ### 3. Conception de l'API **URL de base :** `https://short.url/api/v1` **1. Créer un lien :** * **Point de terminaison :** `POST /links` * **Corps de la requête :** ```json { "long_url": "https://example.com/very/long/url", "custom_alias": "my-custom-alias" // Facultatif "expires_at": "2023-12-31T23:59:59Z" // Facultatif } ``` * **Corps de la réponse :** ```json { "short_url": "https://short.url/xyz123", "long_url": "https://example.com/very/long/url", "custom_alias": "my-custom-alias" // Si fourni } ``` **2. Résoudre un lien (Redirection) :** * **Point de terminaison :** `GET /{short_id}` ou `GET /{custom_alias}` * **Logique :** Le service de résolution de liens gérera cela. Il recherchera d'abord le `short_id` ou le `custom_alias` dans le cache. S'il n'est pas trouvé, il interrogera la base de données de métadonnées. Après avoir récupéré le `long_url`, il enregistrera l'événement de clic et renverra un 301 (Redirection permanente) ou 302 (Redirection temporaire) vers le `long_url`. * **Prévention des abus :** Des vérifications de base pour les modèles malveillants connus ou les URL mises sur liste noire peuvent être effectuées ici. **3. Obtenir les analyses d'un lien :** * **Point de terminaison :** `GET /links/{short_id}/analytics` * **Paramètres de requête :** * `start_time` (horodatage, requis) * `end_time` (horodatage, requis) * `group_by` (chaîne, facultatif, par exemple, "day", "country") * **Corps de la réponse :** ```json { "short_id": "xyz123", "total_clicks": 1500, "clicks_over_time": [ {"timestamp": "2023-10-27T10:00:00Z", "count": 50}, {"timestamp": "2023-10-27T11:00:00Z", "count": 75} ], "clicks_by_country": [ {"country": "US", "count": 1000}, {"country": "EU", "count": 500} ] } ``` **4. Mettre à jour la destination d'un lien (dans les 10 minutes suivant la création) :** * **Point de terminaison :** `PUT /links/{short_id}` * **Corps de la requête :** ```json { "long_url": "https://new.example.com/updated/url" } ``` * **Réponse :** 200 OK ou erreur. ### 4. Stratégie de mise à l'échelle * **Trafic de lecture (Redirections) :** * **Mise en cache :** Mettre en cache agressivement les correspondances `short_id` vers `long_url` dans un cache distribué (par exemple, Redis, Memcached) avec un TTL court (par exemple, 5-10 minutes) pour gérer les pics. Les échecs de cache atteindront la base de données. * **Fragmentation de la base de données :** La base de données de métadonnées sera fragmentée par `short_id` ou un hachage de celui-ci pour répartir la charge. * **Répliques de lecture :** Utiliser des répliques de lecture pour la base de données de métadonnées afin de décharger le trafic de lecture. * **Distribution mondiale :** Déployer des instances du service de résolution de liens dans plusieurs régions proches des utilisateurs. Utiliser GeoDNS pour acheminer les utilisateurs vers la région la plus proche. * **Trafic d'écriture (Création de liens) :** * **Services sans état :** Les instances du service de création de liens doivent être sans état, permettant une mise à l'échelle horizontale facile. * **Service de génération d'ID :** Doit être hautement disponible et évolutif pour gérer le taux de création de nouveaux liens. * **Trafic d'analyse :** * **Traitement asynchrone :** Utiliser une file d'attente de messages (Kafka, Kinesis) pour mettre en mémoire tampon les événements de clic. Cela découple le chemin de redirection du traitement des analyses. * **Pipeline d'analyse évolutif :** Le service d'analyse peut être mis à l'échelle horizontalement pour traiter les messages de la file d'attente et mettre à jour la base de données d'analyse. * **Entrepôt de données :** Pour l'analyse à grande échelle, un entrepôt de données est plus approprié qu'une base de données relationnelle traditionnelle. ### 5. Fiabilité et reprise après sinistre * **Déploiement multi-AZ :** Tous les services et bases de données seront déployés sur plusieurs zones de disponibilité au sein d'une région. * **Déploiement multi-régions :** Pour les services critiques (résolution de liens, API Gateway), déployer sur plusieurs régions géographiques. Utiliser GeoDNS pour le basculement. * **Réplication des données :** Les bases de données auront la réplication activée (par exemple, multi-maître ou maître-réplique avec basculement automatique). * **Idempotence :** Assurer que les opérations critiques (comme la création de liens) sont idempotentes pour gérer les nouvelles tentatives en toute sécurité. * **Dégradation gracieuse :** Si le service d'analyse est en panne, les redirections doivent continuer à fonctionner. Si la base de données de métadonnées est lente, les performances du cache peuvent se dégrader, mais les redirections devraient toujours fonctionner si elles sont mises en cache. * **Sauvegardes :** Sauvegardes automatisées régulières de toutes les données persistantes. ### 6. Compromis clés * **Génération d'ID :** * **Centralisée (par exemple, Snowflake) :** Garantit l'unicité, bonnes performances, mais introduit une dépendance vis-à-vis du service d'ID. Peut être un point de défaillance unique si elle n'est pas hautement disponible. * **Auto-incrément de base de données :** Simple, mais peut être un goulot d'étranglement et plus difficile à mettre à l'échelle sur des fragments/régions. * **Hachage aléatoire :** Plus simple à générer, mais nécessite une détection de collision et peut entraîner des ID plus longs s'ils ne sont pas soigneusement conçus. * **Choisi :** Service de génération d'ID distribué (par exemple, type Snowflake) pour un équilibre entre unicité, performance et disponibilité. * **Sélection de la base de données :** * **NoSQL (Cassandra) :** Excellente pour un débit d'écriture élevé et une mise à l'échelle horizontale, bonne pour la disponibilité. Flexibilité du schéma. Peut être complexe à gérer. * **Relationnel (PostgreSQL fragmenté) :** Forte cohérence, interface SQL familière. La fragmentation ajoute de la complexité. * **Choisi :** Cassandra pour les métadonnées (écritures/lectures élevées, disponibilité) et une base de données de séries temporelles/entrepôt de données pour l'analyse (performances des requêtes). * **Mise en cache :** * **Stratégie d'invalidation de cache :** Le cache-aside avec TTL est courant. Pour les mises à jour (dans les 10 minutes), une invalidation explicite est nécessaire. Pour l'expiration, le TTL s'en charge. * **Cohérence vs Disponibilité :** La mise en cache agressive améliore la disponibilité et la latence, mais peut entraîner des données obsolètes si elles ne sont pas correctement invalidées. * **Choisi :** Cache-aside avec des TTL courts pour les correspondances `short_id` vers `long_url`. Invalidation lors des mises à jour. * **Cohérence :** * **Cohérence éventuelle :** Acceptable pour l'analyse. Pour la résolution de liens, une forte cohérence est préférée mais peut être assouplie avec la mise en cache. * **Création de liens :** Forte cohérence pour l'unicité de `short_id`. Les alias personnalisés peuvent avoir un léger délai de propagation entre les répliques. * **Choisi :** Cohérence éventuelle pour l'analyse. Forte cohérence pour la génération d'ID et l'unicité de la création de liens. Cohérence assouplie pour la résolution de liens via la mise en cache. * **Pipeline d'analyse :** * **Temps réel vs Quasi temps réel :** L'exigence est d'environ 5 minutes. Ceci est réalisable avec le traitement de flux (par exemple, Kafka Streams, Flink) ou le micro-batching. * **Complexité :** Un pipeline temps réel complet est complexe. Une approche de traitement par lots (par exemple, agrégation quotidienne) est plus simple mais ne répond pas à l'exigence de 5 minutes. * **Choisi :** Kafka + traitement de flux (par exemple, Flink ou Spark Streaming) pour une agrégation quasi temps réel dans la base de données d'analyse. ### 7. Surveillance et détection des défaillances * **Indicateurs clés :** * **Latence :** Latence P95/P99 pour l'API Gateway, la création de liens, la résolution de liens et les API d'analyse. * **Taux d'erreurs :** Taux d'erreurs HTTP 5xx et 4xx pour tous les services. * **Débit :** Requêtes par seconde pour la création et la résolution de liens. * **Utilisation des ressources :** CPU, mémoire, E/S réseau, E/S disque pour tous les services et bases de données. * **Taux de réussite du cache :** Pour le cache de lecture. * **Profondeur de la file d'attente :** Pour la file d'attente de messages. * **Performances de la base de données :** Latence des requêtes, nombre de connexions, retard de réplication. * **Outils :** * **Collecte de métriques :** Prometheus, Datadog, CloudWatch. * **Journalisation :** Système de journalisation centralisé (par exemple, pile ELK, Splunk, journaux CloudWatch). * **Traçage :** Traçage distribué (par exemple, Jaeger, Zipkin) pour suivre les requêtes entre les services. * **Alertes :** Alertmanager, PagerDuty pour les problèmes critiques. * **Détection des défaillances :** * **Vérifications de santé :** Implémenter des vérifications de santé approfondies pour tous les services et dépendances. * **Surveillance synthétique :** Pinger régulièrement les points de terminaison critiques (par exemple, créer un lien, résoudre un lien connu) à partir d'emplacements externes. * **Détection d'anomalies :** Surveiller les métriques pour les pics ou les baisses soudaines qui s'écartent des modèles normaux. * **Rollbacks automatisés :** Configurer les pipelines CI/CD pour annuler automatiquement les déploiements si des alertes critiques sont déclenchées. * **Ingénierie du chaos :** Injecter périodiquement des défaillances (par exemple, latence réseau, pannes de service) dans un environnement contrôlé pour tester la résilience.

Architecture de haut niveau et composants principaux Le système est organisé en plusieurs couches déployées dans au moins deux régions géographiques (US-East et EU-West) derrière un DNS anycast global ou un équilibreur de charge global tel qu'AWS Global Accelerator ou Cloudflare. 1. Couche Edge et CDN : Un équilibreur de charge global achemine les utilisateurs vers le cluster régional le plus proche. Un CDN ou un cache edge (Cloudflare Workers, CloudFront) met en cache les mappages de redirection populaires à la périphérie pour atteindre une latence P95 inférieure à 80 ms. 2. API Gateway et limiteur de débit : Chaque région exécute une API Gateway qui gère l'authentification, la limitation du débit et le routage des requêtes. La limitation du débit utilise un compteur à fenêtre glissante soutenu par Redis pour étrangler les modèles de création abusifs. 3. Service de création de liens : Service sans état derrière l'API Gateway. Accepte les URL longues, les alias personnalisés optionnels, l'expiration optionnelle et renvoie un code court. Écrit dans la base de données principale et invalide ou réchauffe le cache. 4. Service de redirection : Le chemin le plus fréquent. Reçoit les requêtes GET sur les codes courts, recherche l'URL de destination (cache d'abord, puis base de données), émet une redirection HTTP 301 ou 302 et publie un événement de clic dans le pipeline d'analyse. Utilise des redirections 302 afin que le service voie toujours la requête pour l'analyse, mais renvoie un en-tête Cache-Control avec un TTL court (par exemple, 60 s) afin que les navigateurs et les bords du CDN puissent mettre en cache. 5. Pipeline d'analyse : Les événements de clic sont publiés dans un flux distribué (Kafka ou AWS Kinesis). Un processeur de flux (Flink ou Kafka Streams) agrège les clics par lien dans des fenêtres de basculement d'une minute et écrit les agrégats dans un magasin d'analyse. Une API simple sert les analyses agrégées. 6. Service de prévention des abus : Lors de la création de liens, l'URL de destination est vérifiée par rapport à l'API Google Safe Browsing et à une liste de blocage interne. Un scoreur ML léger signale les modèles suspects (création en masse, domaines de spam connus). Les liens signalés sont mis en attente pour examen ou rejetés. 7. Travailleur d'expiration et de nettoyage : Une tâche périodique (cron ou Lambda planifiée) recherche les liens expirés et les supprime logiquement, les retirant du cache. Modèle de données de base et choix de stockage Magasin de liens principal : Une base de données NoSQL distribuée telle qu'Amazon DynamoDB ou Apache Cassandra. La table est indexée par short_code (clé de partition). Champs du schéma : short_code (chaîne, clé primaire), long_url (chaîne), user_id (chaîne), created_at (horodatage), expires_at (horodatage, nullable), custom_alias (booléen), updated_at (horodatage). DynamoDB est choisi pour ses lectures en millisecondes à chiffre unique, sa réplication multi-régions automatique via les tables globales et sa mise à l'échelle gérée. Cassandra est une alternative pour les équipes souhaitant éviter le verrouillage fournisseur. Couche de cache : Cluster Redis (ou ElastiCache) dans chaque région. Entrée de cache : short_code -> long_url avec un TTL correspondant à l'expiration du lien ou une valeur par défaut de 24 heures. Modèle de cache-aside : le service de redirection vérifie d'abord Redis ; en cas d'échec, il lit depuis DynamoDB et remplit Redis. Magasin d'analyse : Un magasin de séries chronologiques ou de colonnes. ClickHouse ou Amazon Timestream stocke les agrégats de clics par lien avec les dimensions : short_code, timestamp_bucket, country, referrer, device_type. Agrégats pré-calculés à des granularités de 1 minute, 1 heure et 1 jour. Magasin d'utilisateurs et de comptes : Une base de données relationnelle (PostgreSQL via RDS) stocke les comptes d'utilisateurs, les clés API, la facturation et les métadonnées de propriété des liens. Le trafic est moins important et bénéficie d'une forte cohérence et de requêtes relationnelles. Conception de l'API Créer un lien court : POST /api/v1/links. Corps de la requête : long_url (obligatoire), custom_alias (facultatif), expires_at (facultatif). Réponse : 201 Created avec short_code, short_url, created_at, expires_at. Erreurs : 409 Conflict si l'alias personnalisé est déjà pris, 400 si l'URL est invalide, 403 si un abus est détecté. Mettre à jour l'URL de destination : PATCH /api/v1/links/{short_code}. Corps de la requête : long_url. Autorisé uniquement dans les 10 minutes suivant created_at. Réponse : 200 OK avec l'enregistrement mis à jour. Erreur : 403 si en dehors de la fenêtre de 10 minutes ou si le propriétaire n'est pas celui qui a créé le lien. Résoudre (Redirection) : GET /{short_code}. Réponse : 302 Found avec l'en-tête Location défini sur long_url. Si expiré ou introuvable : 404. Le service de redirection définit également les en-têtes de réponse pour le contrôle du cache. Lire les analyses : GET /api/v1/links/{short_code}/analytics?start=...&end=...&granularity=hour. Réponse : 200 OK avec un tableau de comptes de clics par intervalle de temps, pays principaux, référents principaux. Supprimer un lien : DELETE /api/v1/links/{short_code}. Supprime logiquement le lien et invalide le cache. Stratégie de génération d'ID Les codes courts sont de 7 caractères d'un alphabet base-62 (a-z, A-Z, 0-9), donnant environ 3,5 billions de codes possibles, dépassant largement le volume de liens attendu sur de nombreuses années. Approche de génération : Chaque instance de service se voit attribuer un ID d'Worker unique (provenant d'un service de coordination ou de la configuration). Un générateur d'ID de type Snowflake produit un entier unique de 64 bits combinant un composant d'horodatage, un ID d'Worker et un numéro de séquence. L'entier est ensuite encodé en base-62 et tronqué ou complété à 7 caractères. Cela évite la coordination à chaque écriture et garantit l'unicité. Pour les alias personnalisés, le service tente une insertion avec une contrainte d'unicité ; en cas de conflit, il renvoie 409. Stratégie de mise à l'échelle pour la croissance du trafic et la gestion des pics Mathématiques en régime permanent : 1,5 milliard de redirections par mois, soit environ 580 requêtes par seconde en moyenne, avec des pics lors d'événements d'actualité pouvant atteindre 10 à 50 fois plus, le chemin de redirection doit donc gérer au moins 30 000 RPS par région. La création de liens à 120 millions par mois représente environ 46 RPS en moyenne. Mise à l'échelle du chemin de redirection : Le service de redirection est sans état et peut être mis à l'échelle horizontalement derrière un groupe d'auto-mise à l'échelle. Redis gère la grande majorité des lectures ; la capacité à la demande de DynamoDB gère les échecs de cache. Le cache edge du CDN absorbe une grande partie des requêtes répétées pour les liens viraux, réduisant la charge d'origine. Gestion des pics : Politiques d'auto-mise à l'échelle basées sur le CPU et le nombre de requêtes avec une mise à l'échelle agressive (ajout de 50 % de capacité en 60 secondes). Le cluster Redis peut être pré-mis à l'échelle avec des réplicas de lecture. Le mode à la demande de DynamoDB absorbe les écritures et les lectures de pointe sans pré-provisionnement. Le CDN absorbe naturellement le trafic de lecture de pointe pour les liens populaires. Mise à l'échelle du chemin de création : Moins de pics mais toujours auto-mis à l'échelle. Les écritures vont à la table globale DynamoDB régionale, qui se réplique de manière asynchrone vers d'autres régions. Mise à l'échelle du pipeline d'analyse : Les partitions Kafka sont indexées par short_code pour le parallélisme. Le groupe de consommateurs Flink se met à l'échelle horizontalement. Le cluster ClickHouse peut ajouter des shards pour le débit des requêtes. Fiabilité et reprise après sinistre Actif-actif multi-régions : Les tables globales DynamoDB répliquent les données entre US-East et EU-West avec une résolution de conflit « dernier écrivain gagne ». Les deux régions servent les lectures et les écritures. Si une région tombe en panne, les vérifications de santé DNS (Route 53 ou équivalent) redirigent tout le trafic vers la région survivante en quelques secondes. Réplication Redis : Chaque région possède son propre cluster Redis alimenté par le réplica DynamoDB local. Si Redis tombe en panne, le service de redirection se rabat sur les lectures DynamoDB avec une latence légèrement plus élevée. Durabilité Kafka : Les sujets Kafka ont un facteur de réplication de 3 avec min.insync.replicas=2. Si le pipeline d'analyse prend du retard, les événements de clic sont conservés dans Kafka pendant au moins 72 heures pour relecture. Sauvegardes : La récupération à point nommé de DynamoDB est activée. PostgreSQL dispose de snapshots quotidiens automatisés avec réplication inter-régions. Les données ClickHouse sont sauvegardées sur S3 quotidiennement. Dégradation gracieuse : Si le service de vérification des abus est lent, les requêtes de création se poursuivent avec un drapeau pour un examen asynchrone plutôt que de bloquer. Si le pipeline d'analyse est en panne, les redirections continuent sans être affectées ; les événements de clic sont mis en file d'attente dans Kafka. Compromis clés Génération d'ID : Les ID de type Snowflake évitent un goulot d'étranglement de compteur centralisé mais nécessitent une coordination des ID d'Worker. L'encodage en base-62 des ID de 64 bits produit des codes courts et sûrs pour l'URL. Compromis : des codes légèrement plus longs (7 caractères) que strictement nécessaire pour éviter les collisions et permettre une croissance future. Sélection de la base de données : DynamoDB choisi pour sa mise à l'échelle gérée, ses lectures à faible latence et sa réplication globale intégrée. Compromis : cohérence éventuelle entre les régions (acceptable car la création de liens n'est pas critique en termes de latence entre les régions, et les redirections dans la même région sont cohérentes). Cassandra offrirait des propriétés similaires avec une charge opérationnelle plus importante mais sans verrouillage fournisseur. Mise en cache : Le cache-aside avec Redis fournit des lectures inférieures à la milliseconde pour les liens populaires. Compromis : l'invalidation du cache lors des mises à jour d'URL dans la fenêtre de 10 minutes nécessite une invalidation explicite entre les régions, introduisant une brève fenêtre de données obsolètes (atténuée par des TTL de cache courts pour les liens récemment créés, par exemple, 30 secondes pour les liens de moins de 10 minutes). Cohérence : Le système privilégie la disponibilité et la tolérance aux partitions (AP en termes de CAP). Les lectures de redirection sont éventuellement cohérentes, ce qui est acceptable. La fenêtre de mise à jour de 10 minutes est appliquée au niveau de l'application ; dans de rares scénarios de « split-brain », une redirection obsolète pourrait se produire brièvement. Pipeline d'analyse : Kafka plus Flink plus ClickHouse fournit des analyses quasi en temps réel dans le cadre de l'accord de niveau de service de 5 minutes. Compromis : cela ajoute une complexité opérationnelle. Une alternative plus simple serait d'écrire les journaux de clics sur S3 et d'interroger avec Athena, mais cela ne répondrait pas à l'exigence de fraîcheur de 5 minutes. Redirections 302 vs 301 : 302 (temporaire) est utilisé afin que le service voie chaque clic pour l'analyse. Compromis : latence légèrement plus élevée pour les visiteurs récurrents par rapport à 301, mais le cache edge du CDN avec un TTL de 60 secondes atténue cela tout en capturant la plupart des clics. Surveillance et détection des défaillances Métriques : Chaque service émet des métriques vers un système de surveillance de séries chronologiques (Prometheus plus Grafana, ou CloudWatch). Les métriques clés incluent la latence P50, P95 et P99 des redirections ; le taux de succès du cache (objectif supérieur à 95 %) ; la capacité consommée en lecture et écriture de DynamoDB ; le décalage du consommateur Kafka ; les taux d'erreur par point de terminaison ; le taux de création de liens. Alertes : Alertes PagerDuty si la latence P95 des redirections dépasse 80 ms, si le taux de succès du cache tombe en dessous de 90 %, si le décalage du consommateur Kafka dépasse 5 minutes (SLA d'analyse), si le taux d'erreur est supérieur à 1 % sur n'importe quel point de terminaison, et en cas de défaillance de la vérification de santé d'une région. Traçage distribué : Traces OpenTelemetry sur le chemin de redirection (edge vers cache vers base de données vers réponse) pour diagnostiquer les régressions de latence. Surveillance synthétique : Les requêtes Canary provenant de plusieurs emplacements géographiques créent et résolvent en continu des liens courts, alertant si la latence de bout en bout ou la correction se dégrade. Agrégation de journaux : Journaux structurés expédiés vers un système centralisé (ELK ou CloudWatch Logs) pour le débogage et les pistes d'audit. Vérifications de santé : Chaque service expose un point de terminaison de santé. L'équilibreur de charge supprime les instances non saines. Les vérifications de santé inter-régions déclenchent le basculement DNS. Hypothèses supplémentaires : Les utilisateurs s'authentifient via des clés API pour la création de liens et l'analyse. La création de liens anonymes est limitée par IP. Le système s'exécute sur AWS mais la conception est portable. Les codes courts sont sensibles à la casse. Le service n'a pas besoin de prendre en charge des milliards de liens actifs simultanés à court terme, mais l'espace de codes de 7 caractères permet une croissance jusqu'à des billions.