Monorepo vs Polyrepo Vergleich anhand echter Daten

Die Antwort auf den Monorepo vs Polyrepo Vergleich ist keine Empfehlung, sondern eine Messung. Konkret: Wie viele deiner Features erfordern Änderungen über mehr als eine Service-Grenze hinweg?

Wer diese Zahl nicht kennt, trifft eine Infrastrukturentscheidung auf Basis von Teampräferenzen statt auf Basis von Daten. In einer Engineering-Organisation mit 50 Personen kostet diese Präferenz irgendjemandem einen Sonntag.

Der Schlüsselbegriff ist Kalkulation. Beide Ansätze erzeugen Kosten. Die Frage ist, welche Kosten deine Organisation besser absorbieren kann: die Koordinationssteuer des Polyrepo oder die Tooling-Investition des Monorepo.

PR-Cycle-Time-Daten lösen die Debatte nicht

Faros AI analysierte 320 Engineering-Teams über 12 Monate und stellte fest: Monorepo-Umgebungen haben eine mediane PR-Cycle-Time von 19 Stunden. Polyrepo-Umgebungen: 2 Stunden.

Das ist ein 9,5-facher Unterschied am Median. Am 90. Perzentil schrumpft der Abstand auf 8,6 Tage gegenüber 5,5 Tagen, aber beide Enden sind langsam. Der Mittelwert nähert sich ebenfalls an: 3,6 Tage Monorepo, 2,8 Tage Polyrepo.

Das Gegenargument ist bekannt: Monorepos haben schnellere Build-Zeiten, wenn das Caching funktioniert. Ein Polyrepo-Team, das eine service-übergreifende Änderung über fünf Repositories mit fünf separaten CI-Pipelines und fünf separaten CODEOWNERS-Freigaben koordiniert, schließt einen PR ebenfalls nicht in zwei Stunden.

Die Daten erfassen Cycle-Times für typische PRs, nicht für Worst-Case-Cross-Cutting-Changes. Dieser Unterschied ist entscheidend. Polyrepo-Teams zitieren ihren Median (schnell, weil die meisten PRs isoliert sind). Monorepo-Befürworter beschreiben den Schmerz der repo-übergreifenden Koordination (auch real, dokumentiert in ihren Worst-Case-PR-Tails). Beide Seiten haben für verschiedene Szenarien recht.

Die Daten lösen die Debatte nicht. Sie beschreiben den Kompromiss präziser als ein Bauchgefühl.

Der Blast-Radius, den du nicht berechnest

Hier ist, was selten auf Konferenz-Slides erscheint: In einem Monorepo landet eine defekte gemeinsame Abhängigkeit in jedem Service, der sie importiert, im selben Commit, bevor jemand mit nachgelagertem Ownership die Änderung gereviewed hat.

In einem Polyrepo bricht eine defekte Package-Version die Services, die sie upgraden, aber nur dann, wenn sie upgraden. Der Blast-Radius wird durch die Entscheidung der Consumer aufgeschoben und begrenzt.

Das spielt eine Rolle bei SLO-gated Rollouts. Eine defekte Shared Library in einem Monorepo gibt dir kein Canary-Fenster. Du bekommst einen service-übergreifenden Blast-Radius in einem einzigen Deployment-Ereignis. Dein Error-Budget beginnt über mehrere SLOs gleichzeitig zu brennen, bevor deine Rollout-Automation das Muster erkennen und ein Revert auslösen kann.

In einem Polyrepo ist der Rollout einer Shared-Dependency-Änderung von Natur aus sequenziell. Service A upgradet, und du beobachtest seinen SLO. Service B upgradet drei Tage später. Der Blast-Radius ist zu jedem Zeitpunkt durch die Services begrenzt, die die Änderung bereits übernommen haben.

Die Frage ist nicht, welche Struktur inhärent sicherer ist, sondern was deine Deployment-Primitive ist. Wenn deine Deployment-Einheit der Service mit eigenem SLO-Gate ist, bietet Polyrepo natürliche Isolation. Wenn deine Deployment-Einheit die atomare Feature-Änderung ist, die konsistent über Frontend, API und Background-Worker landet, gibt dir Monorepo diese Koordination ohne Versioning-Drift.

Die meisten Teams, die Microservices deployen, haben das erste Problem. Teams, die eine eng gekoppelte Produktoberfläche ausliefern, das zweite. Entscheidend ist, diesen Unterschied vor der Architekturentscheidung zu klären, nicht danach: Eine Migration in die andere Richtung bei 100+ Engineers ist ein Projekt, das Quartale dauert und Produktarbeit verdrängt.

Warum Polyrepo-Teams bei 50 Engineers an eine Koordinationswand stoßen

Die Koordinationssteuer akkumuliert sich. Bei 8 Engineers ist das Verwalten von vier Repositories lästig, aber machbar. Bei 50 wird es zum Halbtagsjob für mehrere Personen.

Konkrete Anzeichen dafür, dass der Polyrepo-Koordinationsaufwand strukturell geworden ist:

• Dein Platform-Team pflegt ein Shared-Libraries-Repo, das niemand klar verantwortet

• Das Versioning zwischen Services ist so weit auseinandergedriftet, dass ein Bump der Shared Library ein zweiwöchiges Projekt ist

• Ein neuer Engineer kann ohne Kenntnis, welches deiner 23 Repositories er zuerst klonen soll, nicht produktiv arbeiten

• Sicherheits-Patches für gemeinsame Abhängigkeiten erfordern koordinierte PRs über ein Dutzend Repos, mit einem Tracking-Spreadsheet

Das sind keine konstruierten Pathologien. Es sind dokumentierte Failure-Modes von Teams, die 80 Engineers erreicht haben und ihre Repository-Entscheidungen bereut haben.

Besonders kritisch: Das Onboarding neuer Engineers ist ein verlässlicher Frühindikator. Wenn ein Senior Engineer drei Stunden braucht, um die richtige Reihenfolge zum Klonen, Konfigurieren und Starten der lokalen Entwicklungsumgebung herauszufinden, ist die Koordinationslast bereits in der Entwicklererfahrung angekommen -- lange bevor sie in Release-Zeiten sichtbar wird. Das ist kein Dokumentationsproblem. Es ist ein strukturelles Problem, das sich in Deployment-Frequenz und DORA-Metriken niederschlagen wird.

Polyrepo funktioniert, wenn Teams wirklich unabhängig sind: verschiedene Release-Zyklen, verschiedene Tech-Stacks, verschiedene On-Call-Rotationen. Wenn Teams genug Code teilen, dass eine Änderung in einem Service das Nachdenken über drei andere erfordert, wird die Isolation, für die Polyrepo gebaut wurde, zum Mechanismus, der die Koordination schmerzhaft macht.

Der organisatorische Indikator: Zähle, wie viele Slack-Channels existieren, die eigens dazu dienen, repo-übergreifende Releases zu koordinieren. Wenn die Antwort größer als null ist, zahlst du die Koordinationssteuer bereits regelmäßig.

Was Monorepos am 95. Perzentil tatsächlich kosten

Die P90-Daten von Faros AI sind aufschlussreich: 8,6 Tage für Monorepo-PRs am 90. Perzentil. Das ist kein langsames Team, sondern die strukturelle Konsequenz großer Cross-Cutting-Changes, die Koordination über mehrere Code-Owner, breitere CI-Matrizen und Review-Zyklen erfordern, die organisatorische Grenzen überschreiten.

Google hat Bazel. Meta hat Buck gebaut. Nx Cloud und Turborepo Remote Cache existieren, weil der Tooling-Aufwand für ein performantes Monorepo nicht trivial ist. Ein Monorepo mit 200 Engineers ohne affected-only Build Selection, Distributed Caching und automatisierte Merge Queues produziert 45-minütige CI-Runs auf PRs, die eine gemeinsame Utility-Funktion berühren.

Die Tooling-Kosten sind real und werden regelmäßig unterschätzt. Teams, die Monorepos im großen Maßstab erfolgreich betreiben, haben typischerweise Platform-Engineers eingestellt, die sich speziell auf diese Infrastruktur konzentrieren. Ein Monorepo-Tooling nachträglich auf eine wachsende Codebase aufzusetzen und gleichzeitig Produkt zu liefern ist ein Aufwand, der sich in der Deployment-Frequency niederschlägt, bevor er in einem Post-Mortem auftaucht.

Ein weiterer häufig übersehener Kostenfaktor: das Merge-Queue-Management. In einem aktiven Monorepo mit 50 aktiven Entwicklern konkurrieren PRs um den Merge-Slot. Ohne eine automatisierte Merge Queue entstehen implizite Warteschlangen und manuelle Priorisierungsgespräche, die in keinem Velocity-Dashboard sichtbar sind, aber in der gefühlten Entwicklerproduktivität deutlich zu spüren sind.

Wenn dein Platform-Team bereits ausgelastet ist, ist das Hinzufügen von Monorepo-Tooling-Maintenance ein wesentliches Commitment, keine Konfigurationsentscheidung.

Die 30-Prozent-Regel, die leistungsstarke Teams wirklich nutzen

Eine nützliche Heuristik von Teams, die diese Entscheidung bewusst getroffen haben: Wenn mehr als 30% der Features Änderungen über mehrere Service-Grenzen hinweg erfordern, übersteigt der Koordinationsaufwand eines Polyrepo schließlich die Tooling-Investition eines gut geführten Monorepo.

Unter 30% -- wo die meisten Microservices-Organisationen liegen -- überwiegen die Isolationsvorteile des Polyrepo typischerweise die Koordinationssteuer. Service-übergreifende Änderungen kommen vor, aber nicht häufig genug, damit gemeinsames Tooling schneller amortisiert als Isolation.

Das ist messbar. Ziehe deine letzten sechs Monate an gemergten PRs und zähle, wie viele davon Änderungen in mehr als einem Repository erforderten, um ein einzelnes nutzerorientiertes Feature zu shippen. Diese Rate ist dein Input. Sie wird nicht auf eine Dezimalstelle präzise sein, aber sie wird richtungsweisend sein -- und richtungsweisend reicht aus, um die Debatte nicht mehr auf Teampräferenzen laufen zu lassen.

Ein Team mit einer Cross-Service-Rate von 12% braucht kein Monorepo. Ein Team bei 38% und steigend zahlt Koordinationssteuer, die sich weiter akkumulieren wird.

Wie die Rollout-Strategie die Kalkulation verändert

Eine Dimension dieser Entscheidung bekommt fast keine Aufmerksamkeit: deine Rollout-Primitive.

Wenn du prozentbasierte Rollouts mit SLO-Gates fährst -- ein Feature zu 5% des Traffics auslieferst, Error-Budgets beobachtest und dann progressiv erweiterst -- ändert sich deine Blast-Radius-Kalkulation je nachdem, ob das Feature einen oder mehrere Services umfasst.

In einem Polyrepo erfordert ein Multi-Service-Feature-Rollout die Koordination des Rollout-State über Services hinweg. Service A kann bei 20% sein, während Service B noch bei 0% ist, was inkonsistente States erzeugt, über die man unter Incident-Bedingungen schwer nachdenken kann. Feature-Flags helfen, aber du verwaltest weiterhin cross-service Flag-State ohne eine einzige Source of Truth für den Rollout-Fortschritt.

In einem Monorepo mit atomaren Commits landet das Feature konsistent über Services hinweg. Der Rollout kann auf Infrastructure-Ebene weiterhin prozentbasiert sein, aber der Code ist konsistent ab dem Moment des Deployments. Deine SLO-Gates feuern gegen einen kohärenten State.

Teams, die viele atomare Multi-Service-Features ausliefern und progressive Rollouts mit automatischem Rollback bei SLO-Verletzung betreiben, stellen oft fest, dass die Konsistenz des Monorepo eine ganze Kategorie von Incidents eliminiert, für die Polyrepo keinen sauberen Namen hat: den Cross-Service-State-Divergence-Incident, der wie ein Bug aussieht, aber eigentlich ein Deployment-Koordinationsproblem ist.

Was das Post-Mortem wirklich sagen wird

Die meisten Engineering-Organisationen landen bei einem Hybrid, den niemand Hybrid nennt, weil es wie ein architektonischer Kompromiss klingt.

Ein oder zwei Monorepos für eng gekoppelte Produktoberflächen. Separate Repositories für wirklich autonome Services mit unabhängigen Deployment-Zyklen, eigener On-Call-Rotation und einem Team, das in den letzten sechs Monaten keine Shared-Library-Änderung koordinieren musste.

Das Signal, dein aktuelles Setup zu überdenken:

• Die Cross-Service-Change-Frequenz hat 30% überschritten und die CI-Laufzeiten akkumulieren sich

• Du hast Platform-Engineers eingestellt, die kapazitätsmäßig in Monorepo-Tooling investieren können

• Ein Blast-Radius-Incident hat gezeigt, dass deine Polyrepo-Isolation falsch war: Die Services teilten genug Infrastruktur, dass die Isolation Komfort bot, keine Sicherheit

Das Signal, dass die Entscheidung fürs Erste passt:

• Teams sind wirklich unabhängig und der Koordinationsaufwand ist gering

• Dein schlimmster Incident wurde nicht durch cross-service Dependency-Drift verursacht

• Platform-Engineering-Kapazität existiert nicht, um Monorepo-Tooling zu pflegen, ohne die Produktlieferung zu verlangsamen

Das Post-Mortem wird dir sagen, in welchem dieser Zustände du tatsächlich lebst. Dieses Dokument ist in der Regel ehrlicher als der Architecture-Decision-Record, der dem System vorausging, das es beschreibt.