Die Plattform GitHub sieht sich einem beispiellosen Wachstum der Vorgangsdichte im Git-System gegenüber, angetrieben durch die Verbreitung von KI-Software und KI-Agenten (AI Agents), die intensive und kontinuierliche Ströme von Änderungen und Updates generieren. Um den physischen Einschränkungen dertkapazität in herkömmlichen Rechenzentren und Lieferketten zu begegnen, hat das Unternehmen einen Architekturplan vorgestellt, der bisher dazu geführt hat, dass Kopien von 99,99999 % der Repositories gemeinsam in den eigenen Rechenzentren des Unternehmens und der Microsoft Azure-Cloud untergebracht wurden.
Latenz-Hengnis und vollständige Repository-Sperre
GitHub erklärte, dass die am häufigsten genutzten und modifizierten Repositories auf der Plattform – die den verschwindend geringen Restanteil (0,00001 %) ausmachen – vor einer technischen Hürde standen: der Netzwerk-Latenz. Wenn Daten in die zentrale Azure-Region in den USA (Central US) verschoben werden, die etwa tausend Meilen von den Rechenzentren der Plattform entfernt ist, fügt jede Netzwerkverbindung eine Latenz von knapp 25 Millisekunden für den Hin- und Rückweg hinzu.
In der alten Architektur des Synchronisations- und Konsenssystems „Spokes“ erforderte jeder neue Schreibvorgang eine umfassende Sperre auf Ebene des gesamten Repositories (Repository-wide lock), bis die Replikate antworteten. Aufgrund dieser umfassenden Sperre war es die netzwerktechnisch langsamste Kopie, die die Latenzzeit und die Obergrenze für den gesamten Durchsatz des Repositories bestimmte, was zu Engpässen bei aktiven Repositories führte, die häufige Code-Pushes von Entwicklern und KI-Agenten erhalten.
Konsens auf Basis einzelner Referenzen
Um diesen Engpass zu überwinden, hat GitHub den Konsensmechanismus durch die Anwendung seines ersten architektonischen Prinzips neu formuliert: „Koordination reduzieren und unnötige Sperren aufheben“. Anstatt das Repository während der Aktualisierung vollständig zu sperren, gilt der Umfang von Konsens und Sperrung nun ausschließlich für einzelne Referenzen (Per-reference serialization) wie Branches oder Tags.
Da die meisten gleichzeitigen Schreibvorgänge von Entwicklern oder KI-Agenten auf verschiedene Branches abzielen, müssen die Änderungen nicht länger in einer einzigen Warteschlange aufeinander warten. Interne Tests des Unternehmens unter realistischen Lasten zeigten eine 3- bis 4-fache Steigerung der Schreibkapazität bei gleichzeitigem deutlichen Rückgang der Latenz.
Trennung von Speicher und Verarbeitung sowie Verallgemeinerung des Objektspeichers
Die zweite Phase umfasst die Anwendung des zweiten architektonischen Prinzips: „Trennung von Speicher und Rechenkapazität“ (Decoupling storage from compute). Die Mehrheit der Git-Repositories zeichnet sich durch eine hohe Lesedichte im Vergleich zum Schreiben aus, wobei das Verhältnis zwischen 100 und 1.000 Lesevorgängen auf einen einzigen Schreibvorgang liegt. In der alten Architektur konkurrierten Lesen und Schreiben um dieselben Ressourcen und denselben Speicher.
Um dies zu lösen, hat GitHub Azure Blob Storage als virtuelles Mitglied des Konsensgremiums integriert, das als „Virtual Write Replica“ bezeichnet wird. Diese Kopie fungiert als transiente Kette, die Transaktionen bündelt und den Änderungsstrom nachhaltig in den Cloud-Speicher streamt. Sobald die Speicherung bestätigt ist, kann die Plattform eine unbegrenzte Anzahl von virtuellen Lesekopien (Virtual Read Replicas) starten, die bedarfsgross skaliert werden können. Diese Kopien aktualisieren ihren Cache im Hintergrund, ohne die Schreibgeschwindigkeit der Daten oder die Synchronisation zu beeinträchtigen.
Was ändert sich praktisch für die Softwareentwicklungsarchitektur?
Dieser technische Wandel bei GitHub spiegelt wider, wie große verteilte Systeme neu gestaltet werden, um der Natur automatisierter, auf künstlicher Intelligenz basierender Arbeit standzuhalten. Die wichtigsten praktischen Auswirkungen lassen sich wie folgt zusammenfassen:
- Erhöhung der Produktivitätsobergrenze: Ermöglichung intensiver gleichzeitiger Pushes durch KI-Agenten und Entwickler ohne Sperren (Locks) bei großen Repositories.
- Flexibilität bei der Leseskalierung: Die Möglichkeit, Leseserver zu erweitern und ihren Cache unabhängig zuzuordnen, ohne schwere Konsensverfahren durchlaufen zu müssen.
- Kontinuität des Basissystems: Aktualisierung der internen Komponenten des „Spokes“-Systems, das täglich über 100 Milliarden Operationen ausführt, ohne dass der Dienst unterbrochen oder die Datenintegrität geopfert werden muss.