Au cours de l'année écoulée, alors que le trafic Git croissait de façon exponentielle, presque tous les dépôts Git de GitHub ont commencé à vivre à deux endroits à la fois : les centres de données propres de GitHub et Azure. Les dépôts les plus sollicités restent contraints par un seul facteur : un aller-retour de 25 ms entre les régions.
Dans un article précédent, GitHub exposait deux principes qui sous-tendent son architecture de stockage de nouvelle génération : minimiser la coordination et dissocier le stockage du calcul. Cet article examine le pont entre l'ancienne et la nouvelle conception. Une modification de la manière dont le quorum sérialise les écritures a permis de transférer les dépôts les plus sollicités vers Azure, et cette même étape ouvre la voie à des répliques qui ne conservent aucun état persistant propre.
Le calendrier de cette migration a été dicté par le virage vers les agents : un trafic en forte croissance, un plafond strict de la capacité électrique des centres de données de GitHub et de sa région environnante, ainsi que des contraintes physiques dans la chaîne d'approvisionnement. La capacité restante laissait assez de temps pour migrer en sécurité, mais pas pour le faire lentement. Les opérations Git étant un service de niveau 0 dont dépend presque tout ce qui fonctionne sur GitHub, les données devaient d'abord être déplacées, l'architecture évoluant ensuite. La première copie d'un dépôt est arrivée dans la région Central US d'Azure en août 2025. Aujourd'hui, la plupart des dépôts ont deux de leurs cinq répliques dans Azure, et Azure assure environ la moitié du trafic Git.
Les 0,00001 % de dépôts restants posent un problème plus difficile. Dans l'architecture actuelle, une écriture attend la réponse de chaque réplique saine, de sorte que la réplique la plus lente fixe à la fois la latence et le débit. Une réplique située dans la région Azure cible se trouve à environ 1 600 km, et chaque écriture nécessite plusieurs allers-retours. La réponse réside dans la minimisation de la coordination : les exigences de cohérence de Git s'appliquent à chaque référence individuellement, et les mises à jour de références différentes ne dépendent généralement pas les unes des autres, elles n'ont donc pas besoin d'être sérialisées.
Source: Hacker News · Résumé par HeadlinesBriefing