Im vergangenen Jahr, als der Git-Datenverkehr exponentiell wuchs, begannen nahezu alle Git-Repositories auf GitHub, gleichzeitig an zwei Orten zu existieren: in GitHubs eigenen Rechenzentren und in Azure. Die meistgenutzten Repositories sind weiterhin durch einen einzigen Faktor begrenzt: eine Rundreisezeit von 25 ms zwischen den Regionen.
In einem früheren Beitrag stellte GitHub zwei Grundprinzipien seiner Speicherarchitektur der nächsten Generation vor: die Minimierung der Koordination und die Entkopplung von Speicher und Rechenleistung. Dieser Beitrag beleuchtet die Brücke zwischen altem und neuem Design. Eine Änderung daran, wie das Quorum Schreibvorgänge serialisiert, brachte die meistgenutzten Repositories nach Azure, und genau dieser Schritt eröffnet den Weg zu Replikaten, die keinen eigenen persistenten Zustand speichern.
Der Zeitpunkt des Umzugs wurde durch den Wandel hin zu agentischen Systemen bestimmt: schnell wachsender Datenverkehr, eine harte Obergrenze bei der Stromkapazität der GitHub-Rechenzentren und der umliegenden Region sowie physische Lieferkettenengpässe. Die verbleibende Kapazität ließ genug Zeit für eine sichere Migration, aber nicht für eine langsame. Da Git-Operationen ein Tier-0-Dienst sind, von dem nahezu alles auf GitHub abhängt, mussten die Daten zuerst verlagert werden, und die Architektur wurde erst nach ihrer Ankunft weiterentwickelt. Die erste Kopie eines Repositories erreichte im August 2025 die Azure-Region Central US. Heute haben die meisten Repositories zwei ihrer fünf Replikate in Azure, und Azure bedient etwa die Hälfte des Git-Datenverkehrs.
Die verbleibenden 0,00001 % der Repositories stellen ein schwierigeres Problem dar. In der aktuellen Architektur wartet ein Schreibvorgang auf die Antwort jedes gesunden Replikats, sodass das langsamste Replikat sowohl Latenz als auch Durchsatz bestimmt. Ein Replikat in der Zielregion von Azure liegt etwa 1.600 km entfernt, und jeder Schreibvorgang erfordert mehrere Rundreisen. Die Lösung liegt in der Minimierung der Koordination: Die Konsistenzanforderungen von Git gelten für jede Referenz einzeln, und Aktualisierungen unterschiedlicher Referenzen hängen in der Regel nicht voneinander ab, müssen also nicht serialisiert werden.
Quelle: Hacker News · Zusammengefasst von HeadlinesBriefing