Concevoir un service de raccourcissement d'URL

A) Conception de l'API 1) Créer une URL courte - Point d'accès : POST /v1/urls - JSON de requête : - long_url (chaîne, requis, max par ex. 8 Ko) - custom_alias (chaîne, facultatif ; si fourni, doit être unique et passer les tests de jeu de caractères/longueur autorisés) - expire_at (horodatage, facultatif) - metadata (objet, facultatif : par ex. campagne, user_id) - Réponse (201) : - code (chaîne) - short_url (chaîne) - long_url (chaîne) - created_at (horodatage) - expire_at (horodatage|null) - Erreurs : - 400 URL/alias invalide - 409 alias déjà existant - 429 limitation de débit 2) Résoudre/rediriger - Point d'accès : GET /{code} - Comportement : - 301 Redirection permanente par défaut (ou 302 si le suivi/l'expérimentation l'exige) - En-tête Location = long_url - Facultatif : GET /v1/urls/{code} renvoie du JSON au lieu d'une redirection (pour les clients API) - Erreurs : - 404 non trouvé/expiré 3) Supprimer/désactiver (facultatif, pour contrôle des abus/utilisateurs) - Point d'accès : DELETE /v1/urls/{code} - Authentification requise - Réponse : 204 4) Analyses (facultatif, peut être asynchrone/approximatif) - Point d'accès : GET /v1/urls/{code}/stats?from=&to= - Renvoie des compteurs agrégés (clics par jour, référent, géo, etc.) Notes : - Authentification : clés API/OAuth pour la création et la gestion ; les redirections restent publiques. - Idempotence : prendre en charge l'en-tête Idempotency-Key sur POST pour éviter les doublons lors des nouvelles tentatives. B) Modèle de données et stockage Charge de travail - Écritures : 100M nouvelles/mois ≈ 3,33M/jour ≈ 38,6 écritures/sec en moyenne (pic plus élevé). - Lectures : 100:1 => 10 milliards de redirections/mois ≈ 3,86K lectures/sec en moyenne (pics beaucoup plus élevés). Choix du stockage - Stockage principal : magasin clé-valeur distribué / colonne large (par ex. DynamoDB/Cassandra/ScyllaDB) optimisé pour un QPS de lecture très élevé, une faible latence, une mise à l'échelle horizontale et une réplication multi-DC. - Justification : le modèle d'accès est principalement une recherche par clé de code court ; la valeur est petite ; besoin important de haute disponibilité et de latence prévisible. - Systèmes secondaires : - Cache : clusters Redis/Memcached par région. - Pipeline d'analyse : Kafka/PubSub + traitement de flux + magasin OLAP (pas sur le chemin critique). Schéma 1) url_mapping (principal) - Clé de partition : code (chaîne) - Colonnes : - long_url (chaîne) - created_at (horodatage) - expire_at (horodatage|null) - user_id (chaîne|null) - status (actif/supprimé) - checksum (facultatif pour l'intégrité) - TTL : si expire_at est défini, utiliser le TTL natif pour que les entrées expirées soient automatiquement supprimées. 2) alias_reservation (facultatif si prise en charge des alias personnalisés avec unicité) - clé : custom_alias - valeur : code / métadonnées de propriété 3) idempotency (facultatif) - clé : (user_id, idempotency_key) - valeur : code - TTL : par ex. 24h Estimation du stockage (10 ans) - Nouvelles URL en 10 ans : 100M/mois * 12 * 10 = 12 milliards de mappages. - Taille approximative par enregistrement : - code : ~8 octets (ou jusqu'à ~10 caractères) - long_url : moyenne de 200 octets (conservateur), plus les frais généraux - métadonnées/colonnes/frais généraux d'index : moyenne de 100–200 octets selon le magasin - Total effectif (y compris les frais généraux de réplication non encore comptés) : ~400 octets/enregistrement (chiffre de planification raisonnable). - Données brutes : 12 milliards * 400 octets = 4,8 To. - Avec les frais généraux du moteur de stockage + compaction + index secondaires : prévoir ~2–3x => ~10–15 To. - Réplication : - Intra-région (RF=3) : ~30–45 To. - Multi-région (par ex. 2 régions actif-actif) : doubler => ~60–90 To au total dans toutes les régions. (Ce sont des chiffres de planification ; l'exactitude dépend de la longueur moyenne de l'URL et des frais généraux de la base de données.) C) Génération d'URL courtes Objectifs - Aussi courtes que possible - Sans collision à grande échelle - Prend en charge au moins 10 ans de croissance Mathématiques de l'espace clé - Codes totaux nécessaires en 10 ans : 12 milliards. - Utiliser le jeu de caractères Base62 : [0-9][a-z][A-Z] => 62 symboles. - Capacité de longueur L : 62^L. - 62^6 ≈ 56,8 milliards (suffisant pour 12 milliards) - 62^7 ≈ 3,52 billions (plus de marge) Choix - Utiliser une longueur variable avec un minimum de 6 caractères. - Commencer à 6 caractères pour les ~56,8 milliards de premiers codes ; cela couvre déjà l'exigence de 10 ans avec une marge significative (56,8 milliards/12 milliards ≈ 4,7x). - Conserver la possibilité de passer à 7 caractères à l'avenir sans casser les liens existants. Algorithme de génération (sans collisions) Option sélectionnée : identifiants numériques uniques globalement + encodage Base62. - Maintenir un espace d'identifiants 64 bits monotonically increasing. - Encoder l'identifiant en Base62 pour produire le code. - Évitement des collisions : aucun nécessaire car les identifiants sont uniques par construction. Comment générer des identifiants à grande échelle - Utiliser un allocateur d'identifiants distribué similaire à Snowflake, ou un « service d'identifiants » central avec location de plages : 1) Le service d'identifiants stocke un compteur dans un magasin fortement cohérent (par ex. etcd/Spanner) par région. 2) Chaque serveur d'application loue un bloc d'identifiants (par ex. 1 million d'identifiants) pour générer localement. 3) Lorsque le bloc est épuisé, demander un nouveau bloc. - Cela évite la contention par écriture tout en garantissant l'unicité. Gestion des alias personnalisés - Si custom_alias fourni : - Valider le jeu de caractères/la longueur - Écriture conditionnelle (comparer-et-définir) sur url_mapping avec clé=alias ; si existant, renvoyer 409. D) Mise à l'échelle et performances Architecture générale - Anycast/GeoDNS -> Répartiteur de charge global -> répartiteurs de charge L7 régionaux -> serveurs API/redirection sans état. - Services séparés : - Chemin d'écriture : service de création d'URL - Chemin de lecture : service de redirection - Stockage partagé + cache Mise à l'échelle des lectures et des écritures indépendamment - Service de redirection mis à l'échelle horizontalement en fonction du QPS/de la latence (coût probablement dominant). - Service de création mis à l'échelle en fonction du débit d'écriture. - Utiliser des groupes d'autoscaling séparés et des pipelines de déploiement indépendants. Partitionnement des données - Partitionner par hachage de code (ou par le code lui-même) sur les nœuds de la base de données. - Distribution uniforme car les codes sont effectivement uniformes sur l'espace d'identifiants lorsqu'ils sont encodés en Base62. Stratégie de mise en cache - Principal : mise en cache CDN/périphérique pour les redirections + cache en mémoire régional. 1) CDN : - Mettre en cache les réponses 301/302 indexées par chemin (code) avec TTL (par ex. 5–60 minutes, ou respecter expire_at). - Pour les liens extrêmement populaires, le CDN peut absorber la majeure partie du trafic mondial. 2) Cache régional (Redis/Memcached) : - Clé : code - Valeur : long_url + expire_at + status - TTL : min(default_ttl, expire_at-now) - Éviction : LRU ou LFU (préférer LFU pour la popularité biaisée). Taux de succès attendu - Les accès aux URL sont généralement très biaisés (Zipf). Avec CDN + cache régional, un taux de succès de 95–99 % est réalisable pour les redirections ; même 90 % est utile. - Réchauffement du cache : à l'écriture, pousser le mappage dans le cache ; également mise en cache négative pour les échecs (TTL court) afin de réduire les accès répétés à la base de données pour les codes invalides. Atteindre une latence de redirection p95 < 50 ms - Chemin critique pour un succès du cache : - Succès CDN/périphérique : souvent < 20 ms. - Succès du cache régional : LB + application + recherche Redis + réponse : généralement 5–15 ms dans la région. - Pour un échec du cache : - Lecture unique de la base de données à partir de la réplique locale de la région : cible 5–20 ms. - Garder les serveurs de redirection proches des utilisateurs via multi-région + périphérie. - Utiliser keep-alive, HTTP/2 entre les composants, pooling de connexions vers Redis/DB. - Éviter les analyses synchrones ; émettre les événements de clic de manière asynchrone vers une file d'attente. Performances d'écriture - Les écritures sont faibles par rapport aux lectures ; gérer quand même les rafales. - Flux d'écriture : 1) Générer l'ID/le code 2) Écrire dans la base de données (quorum/majorité dans la région) 3) Écriture directe dans le cache 4) Renvoyer la réponse - Facultatif : dédupliquer les long_url identiques en stockant un index hash->code (compromis ; voir F). E) Fiabilité et tolérance aux pannes Objectif de disponibilité : 99,9 % - Multi-AZ dans chaque région pour tous les composants avec état. - Au moins deux régions actif-actif pour le trafic de redirection. Stratégie de réplication - Intra-région : facteur de réplication 3 entre les AZ. - Inter-régions : - Réplication asynchrone pour url_mapping afin de maintenir une faible latence d'écriture et une haute disponibilité. - Les redirections sont servies à partir de la région locale ; si le mappage local est manquant en raison d'un décalage de réplication, basculer vers une autre région (voir ci-dessous). Gestion des pannes de centre de données/région (dégradation progressive) - Utiliser les vérifications de santé du répartiteur de charge global : - Si une région n'est pas saine, rediriger le trafic vers la région saine la plus proche. - Pour les requêtes de redirection : - Si le cache/la base de données régionale est dégradé, le service de redirection peut : 1) Essayer le cache 2) Essayer la base de données locale 3) Si la base de données locale est indisponible, interroger un point d'accès de lecture distant (avec délai d'attente strict) ou utiliser une réplique de lecture inter-régions. 4) Si tout échoue, renvoyer un 503 rapide avec Retry-After (échec progressif). - Pour les requêtes d'écriture : - Préférer les écritures dans la région locale ; si la région est en panne, basculer vers une autre région. - Allocation d'ID : chaque région a son propre espace de noms de bloc d'ID (ou utilise des bits de région dans Snowflake) pour éviter les conflits lors du basculement. Compromis du théorème CAP - Choisir la Disponibilité plutôt que la Cohérence forte pour les opérations globales : - Les redirections doivent être hautement disponibles ; les lectures obsolètes sont acceptables brièvement. - La réplication inter-régions est asynchrone : une URL courte nouvellement créée peut ne pas être résoluble dans une autre région pendant une courte période. Atténuations : - Après la création, renvoyer une URL courte hébergée sur le même domaine de région (ou utiliser un périmètre qui redirige vers la région d'origine pendant les premières minutes). - Lors de la création, éventuellement effectuer une écriture synchrone dans deux régions pour les clients premium/entreprise (latence/coût plus élevés). Sauvegardes et reprise après sinistre - Instantanés périodiques + sauvegardes incrémentielles vers le stockage d'objets. - Exercices de restauration réguliers. F) Discussion des compromis 1) Génération de code basée sur ID vs jetons aléatoires - Choisi : basé sur ID (plage louée/Snowflake) + Base62. - Avantages : - Pas de collisions, pas besoin de boucles de nouvelle tentative. - Planification de capacité prévisible et contraintes de base de données plus simples. - Écritures plus rapides. - Sacrifices : - Les codes sont devinables/séquentiels (sécurité par obscurité non fournie). Atténuation : - Ajouter une « permutation salée » optionnelle (par ex. réseau de Feistel) sur l'identifiant numérique avant l'encodage Base62 pour rendre les codes non séquentiels tout en préservant l'unicité. 2) Réplication inter-régions asynchrone (AP) vs multi-régions synchrone (CP) - Choisi : réplication inter-régions asynchrone. - Avantages : - Latence d'écriture plus faible, disponibilité plus élevée lors de pannes partielles. - Meilleure capacité à continuer de servir les redirections même si une région est défaillante. - Sacrifices : - Cohérence éventuelle : courte fenêtre où une URL nouvellement créée peut ne pas être lisible dans une autre région. Atténuation : - Réparation des lectures/basculement vers la région d'origine pour les liens récents ; écriture double optionnelle pour les clients à haute SLA. 3) Mise en cache intensive/CDN vs accès toujours à la base de données - Choisi : CDN + cache régional. - Avantages : - Atteint facilement < 50 ms p95 et réduit considérablement la charge de la base de données. - Gère les pics de trafic pour les liens viraux. - Sacrifices : - Complexité de l'invalidation du cache (par ex. liens supprimés/expirés). Atténuation : - TTL courts, respect de expire_at, et purge explicite à la suppression pour le CDN lorsque pris en charge ; utiliser des indicateurs de statut et une mise en cache négative avec soin.

A) Conception de l'API : 1. **Point de terminaison de raccourcissement d'URL :** * **Méthode :** `POST` * **Chemin :** `/shorten` * **Corps de la requête (JSON) :** ```json { "long_url": "string", "custom_short_code": "string" (optionnel), "expires_at": "chaîne de date/heure au format ISO 8601" (optionnel) } ``` * **Corps de la réponse (JSON - 201 Created) :** ```json { "short_url": "string", "long_url": "string", "custom_short_code": "string" (si fourni), "expires_at": "chaîne de date/heure au format ISO 8601" (si fourni) } ``` * **Réponses d'erreur :** * `400 Bad Request` : Format de `long_url` invalide ou manquant. * `409 Conflict` : `custom_short_code` existe déjà. * `500 Internal Server Error` : Erreur générale du serveur. 2. **Point de terminaison de redirection d'URL courte :** * **Méthode :** `GET` * **Chemin :** `/{shortCode}` * **Réponse :** Redirection HTTP `302 Found` vers le `long_url`. * **Réponses d'erreur :** * `404 Not Found` : `shortCode` inexistant ou expiré. * `500 Internal Server Error` : Erreur générale du serveur. B) Modèle de données et stockage : **Choix de stockage :** Une base de données relationnelle fragmentée (par exemple, PostgreSQL) avec des réplicas de lecture. **Justification :** * **Cohérence forte pour les écritures :** Essentielle pour garantir l'unicité des codes courts. Les bases de données relationnelles fournissent les propriétés ACID, cruciales pour une intégrité des données fiable lors de la création d'URL. * **Fragmentation bien comprise :** PostgreSQL prend en charge diverses stratégies de fragmentation (par exemple, basée sur la plage, basée sur le hachage) pour distribuer la charge d'écriture et évoluer horizontalement. * **Indexation efficace :** Les index B-tree sont très efficaces pour les recherches ponctuelles sur `short_code`, qui est l'opération principale pour les redirections. * **Réplicas de lecture :** Prend en charge facilement la mise à l'échelle des opérations de lecture (redirections) en ajoutant plusieurs réplicas en lecture seule. * **Maturité et écosystème :** Outils robustes pour la surveillance, la sauvegarde et la récupération. **Schéma :** Table `urls` : * `id` : BIGINT, Clé primaire, Auto-incrémenté (ou généré par un service d'ID distribué). Utilisé comme base pour le code court. * `short_code` : VARCHAR(7), Index unique, NON NULL. La chaîne réelle utilisée dans l'URL. * `long_url` : TEXT, NON NULL. L'URL longue d'origine. * `created_at` : TIMESTAMP WITH TIME ZONE, NON NULL, Défaut : `NOW()`. * `expires_at` : TIMESTAMP WITH TIME ZONE (nullable). Date d'expiration de l'URL courte. * `user_id` : BIGINT (nullable, clé étrangère vers une table `users` si des comptes utilisateurs sont pris en charge). **Estimation du stockage (sur 10 ans) :** * **Volume :** 100 millions d'URL/mois * 12 mois/an * 10 ans = 12 milliards d'URL. * **Estimation de la taille des enregistrements :** * `id` : 8 octets (BIGINT) * `short_code` : 7 octets (VARCHAR(7)) * `long_url` : Moyenne de 100 octets (TEXT, longueur variable) * `created_at` : 8 octets (TIMESTAMP) * `expires_at` : 8 octets (TIMESTAMP) * Total par enregistrement : ~131 octets. * **Taille brute des données :** 12 milliards d'enregistrements * 131 octets/enregistrement = 1,572 To. * **Avec index et surcharge :** En tenant compte des index (en particulier sur `short_code` et `id`), de la réplication et de la surcharge de la base de données, le stockage total pourrait être d'environ 3 à 5 To sur 10 ans. Ceci est gérable avec une architecture de base de données fragmentée. C) Génération d'URL courte : **Algorithme :** 1. Lorsqu'une nouvelle requête de raccourcissement d'URL arrive, un ID unique et croissant est obtenu. Cet ID peut être généré par : * **Auto-incrément de base de données :** Si vous utilisez une base de données fragmentée, chaque fragment peut être configuré avec une plage d'ID unique (par exemple, le fragment 1 utilise les ID 1, 11, 21..., le fragment 2 utilise 2, 12, 22...). * **Générateur d'ID distribué :** Un service dédié comme Snowflake (ou une implémentation personnalisée similaire) peut générer des entiers de 64 bits uniques globalement et ordonnés dans le temps. 2. Cet ID unique est ensuite converti en une chaîne base62. La base62 utilise 62 caractères (0-9, a-z, A-Z), ce qui permet une représentation compacte. **Évitement des collisions :** * En dérivant le code court d'un ID unique globalement (soit par auto-incrément fragmenté, soit par un générateur d'ID distribué), les collisions sont intrinsèquement évitées. Chaque ID généré est unique, et sa représentation base62 le sera également. * Pour les requêtes `custom_short_code`, le système tente d'insérer le code fourni par l'utilisateur. Si un conflit survient (en raison d'une entrée existante), une erreur `409 Conflict` est renvoyée à l'utilisateur. **Jeu de caractères et longueur :** * **Jeu de caractères :** Base62 (0-9, a-z, A-Z) - 62 caractères uniques. * **Longueur :** 6 caractères initialement. **Justification mathématique de la suffisance de l'espace clé :** * **Volume requis :** 12 milliards d'URL uniques sur 10 ans. * **Espace clé avec 6 caractères :** 62^6 = 56 800 235 584 (environ 56,8 milliards de codes uniques). * Cet espace clé (56,8 milliards) est significativement plus grand que les 12 milliards d'URL requis, offrant une marge de croissance suffisante et garantissant la suffisance pour au moins 10 ans. Si le service dépassait cela, la longueur du code court pourrait être étendue à 7 caractères, fournissant 62^7 (environ 3,5 billions) de codes uniques. D) Mise à l'échelle et performances : **Mise à l'échelle des lectures (redirections) :** * **Cache distribué (par exemple, Redis Cluster) :** Le principal mécanisme de mise à l'échelle pour les lectures. Les correspondances `short_code` -> `long_url` sont stockées dans un cache distribué hautement disponible. Compte tenu du ratio lecture/écriture de 100:1, la plupart des requêtes de redirection seront servies directement depuis le cache. * **Réplicas de lecture de base de données :** Les instances PostgreSQL fragmentées auront plusieurs réplicas de lecture. En cas de cache manqué, la requête se rabat sur un replica de lecture. Les équilibreurs de charge distribuent les requêtes entre ces réplicas. * **Réseau de diffusion de contenu (CDN) :** Bien qu'il ne mette pas directement en cache la redirection 302, un CDN peut servir des actifs statiques et potentiellement optimiser le routage pour les requêtes initiales, réduisant la latence pour les utilisateurs géographiquement dispersés. **Mise à l'échelle des écritures (raccourcissements) :** * **Fragmentation de base de données :** La stratégie principale. Les données sont partitionnées sur plusieurs instances PostgreSQL en fonction d'une clé de fragmentation (par exemple, l'`id` à partir duquel le `short_code` est dérivé). Cela distribue la charge d'écriture et les exigences de stockage. * **Regroupement de connexions :** Gère efficacement les connexions à la base de données pour réduire la surcharge. * **Traitement asynchrone :** Pour les tâches non critiques (par exemple, analyse, journalisation, mise à jour des statistiques), les files d'attente de messages (par exemple, Kafka, RabbitMQ) peuvent décharger le travail du chemin d'écriture principal, améliorant la réactivité. **Stratégie de mise en cache :** * **Type de cache :** Cache distribué en mémoire (par exemple, Redis Cluster). * **Données mises en cache :** Correspondances `short_code` vers `long_url`. * **Remplissage du cache :** Lors d'un raccourcissement d'URL réussi, la nouvelle correspondance est écrite à la fois dans la base de données et dans le cache. Lors d'un cache manqué pendant une redirection, la correspondance est récupérée de la base de données, puis écrite dans le cache (write-through/write-aside). * **Politique d'éviction :** LRU (Least Recently Used) est approprié. Les URL populaires resteront dans le cache, tandis que celles moins fréquemment consultées seront évacuées pour faire de la place. Un délai d'expiration (TTL) peut également être appliqué, en particulier pour les URL avec un champ `expires_at`. * **Taux de succès attendu :** Compte tenu du ratio lecture/écriture de 100:1 et de la distribution de puissance de l'accès aux URL (un petit pourcentage d'URL représente un grand pourcentage du trafic), un taux de succès de cache de 90-95 %+ est très réalisable, réduisant considérablement la charge de la base de données. **Respect de l'exigence de latence p95 de 50 ms :** * **Taux de succès de cache élevé :** La grande majorité des requêtes de redirection seront servies à partir du cache distribué, qui peut répondre en quelques millisecondes. * **Accès optimisé à la base de données :** Pour les cache manqués, l'indexation efficace sur `short_code` dans la base de données fragmentée garantit des recherches rapides. * **Proximité et réseau :** Déploiement des services dans plusieurs régions proches des utilisateurs et utilisation d'une infrastructure réseau à haute vitesse et faible latence. * **Équilibrage de charge :** Distribution efficace des requêtes entre les instances de service saines et les réplicas de base de données. * **Serveurs d'applications sans état :** Permet une mise à l'échelle horizontale facile de la couche API, garantissant une capacité suffisante pour gérer les charges de pointe sans devenir un goulot d'étranglement. D) Fiabilité et tolérance aux pannes : **Pannes de centre de données :** * **Déploiement multi-régions :** L'ensemble du service (serveurs d'API, clusters de cache, fragments de base de données) est déployé dans au moins deux centres de données/régions géographiquement distincts. * **Équilibreur de charge global (par exemple, gestion du trafic basée sur DNS) :** Dirige le trafic utilisateur vers la région saine la plus proche. Si une région tombe en panne, le trafic est automatiquement redirigé vers la région opérationnelle. * **Basculement automatique :** Les clusters de bases de données sont configurés pour un basculement automatique au sein d'une région (primaire vers replica) et entre les régions (configuration actif-passif ou actif-actif). **Stratégie de réplication des données :** * **Base de données (PostgreSQL) :** * **Au sein d'une région :** La réplication en flux synchrone est utilisée entre l'instance de base de données primaire et ses réplicas locaux. Cela garantit aucune perte de données en cas de défaillance du primaire au sein du même centre de données. * **Entre les régions :** La réplication en flux asynchrone est utilisée de la primaire dans la région active vers un replica dans la région passive/de secours. Cela offre des capacités de reprise après sinistre avec un impact minimal sur les performances du chemin d'écriture principal. Dans une configuration actif-actif, la primaire de chaque région répliquerait de manière asynchrone vers l'autre. * **Cache distribué (Redis Cluster) :** Les données sont fragmentées et répliquées sur plusieurs nœuds au sein de chaque cluster Redis. Chaque fragment a une primaire et au moins un replica. En cas de défaillance d'un nœud, un replica est promu au rang de primaire. **Compromis (Théorème CAP) :** * **Choix :** Privilégier la **Disponibilité (A)** et la **Tolérance aux partitions (P)** par rapport à la **Cohérence (C)** forte pour les opérations de lecture (redirections), tout en maintenant une cohérence forte pour les opérations d'écriture (raccourcissement) au sein d'un fragment de base de données. * **Justification :** Pour un service de raccourcissement d'URL, il est plus critique que le service reste disponible et réactif (faible latence) même en cas de partitions réseau ou de pannes de centre de données. Les utilisateurs s'attendent à ce que les redirections fonctionnent rapidement. * **Comment c'est réalisé :** * **Disponibilité :** Le déploiement multi-régions, l'équilibrage de charge global, les réplicas de lecture de base de données et un cache distribué hautement disponible garantissent que les requêtes peuvent toujours être servies. * **Tolérance aux partitions :** La nature distribuée du système (fragmentation, réplication) gère intrinsèquement les partitions réseau. * **Cohérence :** Pour les écritures, une cohérence forte est maintenue au sein d'un fragment de base de données. La réplication inter-régions est asynchrone, ce qui signifie qu'il peut y avoir une petite fenêtre d'incohérence entre les régions pour les URL nouvellement créées. Le cache sert également de couche de cohérence éventuelle, car il est mis à jour lors des écritures et lors des cache manqués. F) Discussion des compromis : 1. **Cohérence vs. Disponibilité pour les redirections (Théorème CAP) :** * **Choix :** Privilégier la **Disponibilité** et la **Tolérance aux partitions** par rapport à la **Cohérence forte** immédiate pour le chemin de redirection. * **Pourquoi :** L'objectif principal d'un raccourcisseur d'URL est de fournir des redirections rapides et fiables. Si une URL nouvellement créée prend quelques secondes pour se propager à tous les réplicas de lecture et caches mondiaux, c'est une inconvénient mineur. Cependant, si le système attendait la cohérence mondiale avant de servir une redirection, cela introduirait une latence significative et réduirait la disponibilité lors de partitions réseau ou de pannes régionales. Les utilisateurs préféreraient rencontrer un rare 404 pour une URL toute nouvelle plutôt que des délais d'attente fréquents ou des redirections lentes. * **Sacrifice :** Une petite fenêtre de cohérence éventuelle. Un utilisateur pourrait créer une URL dans la région A, et s'il essaie immédiatement d'y accéder depuis la région B (avant que la réplication asynchrone ne soit terminée), il pourrait temporairement recevoir un 404. Dans des scénarios extrêmes de pannes multi-régions avec réplication asynchrone, il existe un faible risque de perte de données pour les écritures très récentes si la région primaire tombe en panne catastrophiquement avant que la réplication vers la région secondaire ne soit terminée. * **Gain :** Haute disponibilité (99,9 % de disponibilité) et latence extrêmement faible (p95 inférieure à 50 ms) pour la grande majorité des requêtes de redirection, qui sont les opérations les plus fréquentes. Le système reste opérationnel et réactif même si un centre de données est hors service. 2. **Méthode de génération de code court (ID séquentiel vers Base62 vs. Hachage de l'URL longue) :** * **Choix :** Générer des codes courts en convertissant un ID unique et croissant séquentiellement (provenant d'un générateur d'ID distribué ou d'un auto-incrément fragmenté) en Base62. * **Pourquoi :** Cette méthode garantit l'unicité par conception, simplifiant le chemin d'écriture et améliorant les performances. Elle évite les complexités et la surcharge de performance associées à la détection et à la résolution des collisions inhérentes aux approches basées sur le hachage. * **Sacrifice :** Les codes courts peuvent apparaître quelque peu séquentiels (par exemple, `abcde1`, `abcde2`). Cela pourrait être une préoccupation esthétique mineure pour certains utilisateurs, mais cela n'affecte pas la fonctionnalité. De plus, cela nécessite un mécanisme de génération d'ID distribué robuste, qui ajoute un composant à l'architecture. * **Gain :** * **Unicité garantie :** Pas de collisions, éliminant le besoin de recherches en base de données et de nouvelles tentatives lors de la génération de codes courts, ce qui est essentiel pour un débit d'écriture élevé (100 millions/mois). * **Chemin d'écriture simplifié :** Le processus de création d'une nouvelle URL courte est une opération d'insertion simple après la génération de l'ID. * **Espace clé prévisible :** Plus facile à gérer et à garantir que l'espace clé est suffisant pour la croissance future. * **Flexibilité :** Permet à la même `long_url` d'être raccourcie plusieurs fois, produisant différents `short_code` si désiré (par exemple, pour suivre différentes campagnes), ce qui n'est pas possible avec un simple hachage de la `long_url`.