Warum wir meist mit einem modularen Monolithen beginnen
Für die meisten Systeme ist ein modularer Monolith die günstigere Wahl — bis eine konkrete Grenze verteilte Dienste wirklich verlangt.
Was ist das? · Standpunkt
Eine begründete Position — mit These, Abwägung und dem Fall, in dem wir anders entscheiden würden. Kein neutraler Überblick, sondern eine Haltung. Zur Übersicht
Worum es geht.
Microservices gelten oft als Standard für ernsthafte Software. In der Praxis zahlen viele Teams die Kosten verteilter Systeme — Netzwerkgrenzen, eventual consistency, Betriebsaufwand — bevor sie deren Nutzen brauchen. Wir beobachten das seit Jahren und entscheiden bewusst dagegen, solange nichts dafür spricht.
Warum wir das so sehen.
Komplexität sollte der Notwendigkeit folgen
Ein modularer Monolith erlaubt klare Modulgrenzen innerhalb einer Codebasis und eines Deployments. Die Grenzen sind explizit, aber ihre Überschreitung kostet keinen Netzwerk-Hop.
Änderungen bleiben lokal
Eine Änderung über mehrere Module ist ein Commit und ein Deployment — kein koordinierter Rollout über mehrere Dienste mit Versionsverträgen.
Der Betrieb ist einfacher
Ein Deployment, ein Log-Strom, eine Transaktion. Vieles, was verteilte Systeme an Werkzeugen und Disziplin verlangen, ist hier schlicht nicht nötig.
Die Entscheidung bleibt offen
Sauber geschnittene Module lassen sich später gezielt herauslösen. Der modulare Monolith schließt Microservices nicht aus — er verschiebt die Entscheidung, bis sie fundiert fällt.
Was es kostet.
Ohne Moduldisziplin kann ein Monolith zum großen Ball aus Schlamm werden. Das Muster schützt nicht vor schlechten Grenzen — es macht sie nur billiger zu korrigieren.
Unabhängige Skalierung einzelner Teile ist nicht möglich; der Dienst skaliert als Ganzes.
Sehr große Teams, die vollständig unabhängig ausliefern müssen, stoßen an die Grenzen einer gemeinsamen Codebasis.
Wann wir anders entscheiden.
Wenn Teile eines Systems radikal unterschiedliche Skalierungs- oder Verfügbarkeitsanforderungen haben.
Wenn mehrere Teams nachweislich unabhängig ausliefern müssen und Koordination im Monolithen teurer wird als verteilte Grenzen.
Wenn eine Domänengrenze so stabil und klar ist, dass ihre Verteilung messbar mehr bringt als kostet.
Wie wir es halten.
Wir bevorzugen den modularen Monolithen nicht aus Prinzip, sondern weil er die teuren Entscheidungen offen hält. Verteilte Systeme sind ein Werkzeug für konkrete Probleme — nicht der Ausgangspunkt.
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Verwandte Konzepte
Engineering-Entscheidungen
Andere Sicht? Sprechen wir darüber.
Standpunkte sind zum Prüfen da. Wenn Sie das anders sehen — oder ein konkretes Problem haben — sprechen Sie mit der Geschäftsführung.
