Git ist längst zum Industriestandard geworden, doch das Hosten von Repositorys im großen Maßstab bleibt eine enorme technische Herausforderung. Das liegt vor allem an der Architektur von Git selbst, die dezentrale Packfiles zwingend auf dem Dateisystem vorsieht. Cursor stellt mit Continuity und der Plattform Origin einen völlig neuen Ansatz vor, der auf einem Write-Ahead Log in S3 basiert und dabei bewährte Prinzipien mit frischen Ideen verbindet. In diesem Artikel beleuchten wir die technischen Hürden des Git-Hostings und zeigen, wie Continuity diese elegant löst.
Die Packfile-Falle
Git wurde als verteiltes Versionskontrollsystem konzipiert. In der Praxis verlassen sich Unternehmen jedoch auf zentrale Server. Das zentrale Element der Git-Speicherung sind Packfiles – komprimierte Binärdateien, die Code und Metadaten enthalten. Sie sind für lokale Arbeit optimiert, stellen Serverbetreiber aber vor große Probleme.
Packfiles müssen auf einem Dateisystem liegen, um effizient lesbar zu sein. Sie speichern Objekte in einem gerichteten azyklischen Graphen. Wer also ein einzelnes Objekt lesen will, muss oft mehrere physische und logische Sprünge im Packfile ausführen. Das macht Verteilung und Skalierung extrem aufwendig.
Von Google bis GitHub: Gelernt aus dem Scheitern
Objekte verteilen
Die Idee, Git-Objekte über einen verteilten Hash-Table zu speichern, wurde beispielsweise bei Google mit JGit ausprobiert. Das scheiterte jedoch am Git-Protokoll selbst: Der Client erwartet Packfiles über das Netzwerk. Die Umwandlung der Daten führte zu so schlechten clone-Performancewerten, dass der Ansatz verworfen wurde.
Dateisysteme verteilen
GitHub begann 2008 mit einem einfachen Rails-Monolithen und lokalen Festplatten. Um zu skalieren, wurden verteilte Dateisysteme wie NFS, GFS oder DRBD getestet. Alle scheiterten an den spezifischen Anforderungen von Git an Dateisystem-Semantik, insbesondere an den zufälligen Zugriffsmustern innerhalb der Packfiles.
Spokes und die Konsistenzfalle
Die Lösung namens Spokes, die bei GitHub ab 2013 entwickelt wurde, hat sich als Industriestandard etabliert. Spokes repliziert Git-Repositorys auf lokale NVMe-Laufwerke und synchronisiert alle Kopien strikt über einen Three-Phase-Commit (3PC). Das funktioniert, ist aber komplex: Es erfordert Quoren, konsensbasierte Verteilung und aufwendiges Tracking, welches Repository auf welchem Server liegt.
Continuity: Die S3-basierte Revolution
Cursor entwickelte Continuity mit dem Ziel, die Stärken von Spokes zu übernehmen und die Schwächen zu beheben. Die zentrale Designentscheidung: ein Write-Ahead Log (WAL) in S3-kompatibler Objektspeicherung.
Jeder Push wird als WAL-Eintrag gespeichert. Der Push wird erst bestätigt, wenn er vollständig in S3 persistiert ist. Ein Push wird erst sichtbar, wenn die Referenztransaktion lokal vorbereitet und ein Zeiger im WAL-Index gesetzt wurde. Das macht alle Operationen linearisierbar.
Zustandslosigkeit statt Konsens
Im Gegensatz zu Spokes gibt es bei Continuity keine festen Primärserver und keine Routing-Tabellen. Repositorys leben als warmer Cache auf der lokalen NVMe-Platte, die Quelle der Wahrheit ist immer S3. Fehlende Repositorys werden bei Bedarf einfach aus dem WAL materialisiert. Dank Rendezvous Hashing weiß das System zwar, wo es Repositorys vorrangig erwartet, doch Ausfälle oder Topologie-Änderungen stören den Betrieb nicht.
Optimistische Replikation und echte Skalierung
Die Replikation erfolgt über optimistische UDP-Gossip-Pakete. Verliert sich ein Paket, ist das irrelevant, da alle Lesevorgänge direkt gegen S3 validiert werden. Das ermöglicht vollständig konsistente horizontale Skalierung: Leseoperationen skalieren linear mit der Anzahl der Repliken. Ein großes Monorepo kann auf hunderten von Knoten laufen, kleine Repositorys genügen mit einer einzigen Kopie.
Komprimierung und operative Einfachheit
Packfiles müssen regelmäßig komprimiert werden, damit die Performance nicht sinkt. Bei Spokes muss jeder Knoten eigenständig repacken – eine CPU-intensive Operation, die Ausfälle verursachen kann. Bei Continuity führt nur der Primärknoten die Komprimierung durch und schreibt das Ergebnis in die WAL. Repliken laden die optimierten Packfiles aus S3 herunter und sparen so CPU ein.
Das Ergebnis: Lineare Skalierung
Im Produktiveinsatz zeigt sich die Leistungsfähigkeit des Systems. Mit S3 Standard werden bis zu 120 Pushes pro Sekunde bei gleichzeitiger Replikation und Komprimierung erreicht. Auf S3 Express One Zone steigt der Wert auf über 300 Pushes pro Sekunde – begrenzt dann nur noch durch die Geschwindigkeit, mit der Git die On-Disk-Daten komprimieren kann.
Synthetische Stresstests mit bis zu 100 Repliken bestätigen eine lineare Skalierung für Lesezugriffe ohne Einbußen bei der Push-Durchsatzrate.
Dauerhaftigkeit und Fehlertoleranz
Die WAL-basierte Architektur bietet einen entscheidenden Vorteil: vollständige Provenienzdaten. Jeder Zustand des Repositorys ist nachvollziehbar. Bei Datenkorruption oder Bugs lässt sich exakt rekonstruieren, was geschah, und der Zustand gezielt zurückgesetzt werden. Weil alle Git-Operationen auf einem standardkonformen Repository auf der lokalen NVMe-Platte ausgeführt werden, bleibt die Kompatibilität mit der offiziellen Git-Toolchain erhalten.
Fazit und Ausblick
Mit Origin bietet Cursor eine Plattform, die aus jahrzehntelanger Erfahrung im Betrieb großer Git-Infrastrukturen entstanden ist. Der Ansatz vereint Einfachheit, strenge Konsistenz und horizontale Skalierbarkeit – und das, ohne externe Datenbanken oder komplexe Konsensalgorithmen zu benötigen. Für Unternehmen, die ihre Versionskontrolle zuverlässig und zukunftssicher betreiben wollen, liefert Continuity eine überzeugende technische Grundlage.
Quelle: cursor.com/blog/git-at-any-scale
