architecture

Mitwachsende Architekturen: Skalierbar wachsen ohne Relaunch

Wie B2B-SaaS-Teams Software so entwerfen, dass sie mit dem Geschäft wächst — ohne den teuren Rewrite nach 18 Monaten. Modulith-First, Strangler-Fig, Fitness Functions.

AutorAnna HartungVeröffentlicht30. April 2026Lesezeit12 Min.

• architektur
• skalierung
• modulith
• microservices
• saas-architektur
• evolutionary-architecture

Viele B2B-SaaS-Startups im DACH-Raum starten mit einem klaren Ziel: schnell launchen, Kunden gewinnen, skalieren. Was nach 12 bis 18 Monaten Wachstum häufig passiert, ist ein anderes Bild. Die ursprüngliche Architektur wird zum Engpass, neue Features kosten dreimal so viel Zeit wie geplant, und das Engineering-Team spricht plötzlich von einem notwendigen Rewrite.

Genau diese Situation ist vermeidbar.

Dieser Leitfaden erklärt, was mitwachsende Architekturen wirklich bedeuten, welche Mechanismen dahinterstecken und welche konkreten Strategien SaaS-Teams helfen, den Relaunch-Trap zu umgehen.

---

Inhaltsverzeichnis

• Definition und Ursprung
• Mechanik und Frameworks
• Konkrete Strategien und Fallstricke
• Monolith First oder Microservices?
• Was Skalierbarkeit in SaaS wirklich verlangt
• Architekturberatung: Von der Vision zur Realität
• Häufig gestellte Fragen

---

Wichtige Erkenntnisse

Punkt	Details
Mitwachsen statt Relaunch	Eine mitwachsende Architektur passt sich dem Wachstum an und vermeidet teure Systemwechsel.
Evolution statt Big Bang	Modulare Systeme erlauben schrittweisen Umbau und verkürzen Zyklen messbar.
Metriken und Monitoring	Kohäsion, Kopplung und frühe Observability sind die Schlüsselfaktoren.
Fallstricke vermeiden	Over-Engineering und Vendor Lock-in kosten viel — proaktive Strategie sichert Flexibilität.

---

Definition und Ursprung von Mitwachsenden Architekturen

Bevor wir in die Praxis gehen, ein Blick darauf, was hinter dem Begriff steckt — und warum er für B2B-SaaS so vielversprechend ist.

Der Begriff »mitwachsende Architektur« stammt nicht aus der Softwareentwicklung, sondern aus dem Bauwesen. Er beschreibt Strukturen, die modular erweiterbar gebaut werden, sodass spätere Umbauten ohne vollständigen Abriss möglich sind.

In der Softwareentwicklung wird der Begriff metaphorisch verwendet. Mitwachsende Architekturen sind kein etablierter Standardbegriff, sondern stehen für skalierbare, evolvable Systeme, die mit dem Geschäft wachsen — ohne Relaunch. Das ist eine wichtige Abgrenzung: Ein System, das mitwächst, ist nicht eines, das von allein skaliert. Es braucht gezielte Entscheidungen, klare Modulgrenzen und eine bewusste Architekturstrategie.

Mitwachsen heißt nicht automatisches Wachsen. Es heißt, dass das System so entworfen wurde, dass Wachstum möglich ist, ohne alles neu zu bauen.

Eine skalierbare Softwarearchitektur zu bauen, verlangt von Anfang an die Trennung von Verantwortlichkeiten, klare API-Grenzen und eine Infrastruktur, die horizontale Erweiterung erlaubt. Die Abgrenzung zu klassischen Begriffen ist dabei wichtig:

• Monolith: Alle Komponenten in einer Codebasis, ohne explizite Modulgrenzen.
• Microservices: Vollständig getrennte Dienste mit eigenem Deployment-Zyklus und eigener Datenhaltung.
• Mitwachsende Architektur: Ein pragmatisches Spektrum zwischen beiden Polen, das auf Architecture-First-Engineering setzt und Modularität als Grundprinzip verankert.

Die Ziele dieser Denkweise: Kostenreduktion durch vermiedene Rewrites, Flexibilität bei Technologieentscheidungen und Anpassungsfähigkeit an veränderte Business-Anforderungen. Wer früh in diese Prinzipien investiert, spart später die Größenordnung — nicht den Bruchteil.

---

Mechanik und Frameworks: Wie Mitwachsende Architekturen funktionieren

Die Mechanik beruht auf einem klaren Grundprinzip: Start mit einem modularen Monolithen, schrittweiser Übergang zu Microservices via Strangler-Fig-Pattern oder Evolutionary Architecture. Das ermöglicht inkrementelle Skalierung ohne Big-Bang-Relaunch.

Die wichtigsten Architekturtypen im Überblick:

Architekturtyp	Einsatzphase	Komplexität	Skalierbarkeit
Modularer Monolith	MVP bis Series A	Niedrig	Mittel
Modulith mit Domain Events	Series A bis B	Mittel	Hoch
Microservices	Post-Series A	Hoch	Sehr hoch
Strangler-Fig-Migration	Jederzeit möglich	Mittel	Hoch

Das Strangler-Fig-Pattern verdient besondere Aufmerksamkeit. Es beschreibt eine Migrationsstrategie, bei der neue Funktionen außerhalb des bestehenden Systems gebaut werden, während alte Teile schrittweise ersetzt werden. So lässt sich eine Legacy-Codebasis modernisieren, ohne das System je vollständig abzuschalten.

Studien aus dem Enterprise-Umfeld berichten von rund 30 % reduzierten Wartungskosten und Features, die bis zu 40 % schneller umgesetzt werden — wenn evolutionäre Architekturprinzipien konsequent angewendet werden. Das sind keine theoretischen Zahlen, sondern Ergebnisse aus inkrementeller Modularisierung.

Ein typischer Fahrplan vom MVP zur skalierbaren Plattform:

1. Phase 1 (MVP): Modularer Monolith mit klar definierten Domänengrenzen, sauber getrennten Packages und einer einheitlichen Datenbankschicht.
2. Phase 2 (Growth): Einführung von Domain Events und asynchroner Kommunikation innerhalb des Monolithen, Vorbereitung für spätere Service-Extraktion.
3. Phase 3 (Scale): Extraktion erster hochlastiger Module als eigenständige Services via Strangler-Fig — ohne dass das Gesamtsystem neu geschrieben wird.
4. Phase 4 (Enterprise): Vollständige Microservices-Architektur für kritische Domänen, Event Sourcing für Auditierbarkeit, DSGVO-konforme Datentrennung.

Erfahrene SaaS-Teams berichten in den Engineering-Perspektiven, dass die größten Fehler nicht in der Technologiewahl liegen, sondern in mangelnder Planung der Modulgrenzen.

Profi-Tipp: So einfach wie möglich starten. Evolution zählt mehr als Perfektion am Tag eins. Ein gut strukturierter Monolith mit klaren Domänengrenzen ist deutlich besser als ein schlecht geplantes Microservices-System.

Enterprise-Engineering für Gründer beginnt immer mit einer Frage: Welche Module werden morgen unabhängig skaliert werden müssen? Diese Antwort prägt die Architekturentscheidungen von heute.

---

Konkrete Strategien und Fallstricke bei Wachstum

Wenn ein B2B-SaaS-Produkt wächst, entstehen Skalierungsprobleme oft nicht dort, wo man sie erwartet. Der Engpass liegt selten im Hauptpfad, sondern in Randfunktionen wie Reporting, Webhooks oder Benachrichtigungen.

Drei Skalierungsstrategien, die für SaaS-Architekturen besonders relevant sind:

• Sharding: Aufteilung der Datenhaltung auf mehrere Datenbank-Instanzen nach Mandanten oder Domänen — besonders relevant für Multi-Tenant-SaaS.
• Stateless Design: Services speichern keinen lokalen Zustand. Horizontales Scaling wird ohne Datenverlust möglich.
• Multi-Cloud-Strategie: Verteilung kritischer Workloads auf mehrere Cloud-Anbieter — erhöht Ausfallsicherheit und reduziert Vendor Lock-in.

Die kritischen Edge Cases umfassen Cold Starts in Serverless-Architekturen, Distributed Tracing bei Eventual Consistency, Vendor Lock-in durch proprietäre Dienste und fehlende Observability. Diese Probleme kosten SaaS-Teams Wochen an Engineering-Zeit, wenn sie erst nach dem Launch adressiert werden.

Vergleich der Architekturen nach Skalierungsanforderungen:

Kriterium	Monolith	Microservices
Initiale Komplexität	Niedrig	Hoch
Deployment-Aufwand	Gering	Hoch
Skalierbarkeit einzelner Komponenten	Begrenzt	Sehr gut
Observability-Aufwand	Niedrig	Hoch
Eignung für MVP	Sehr gut	Eingeschränkt
Langfristige Flexibilität	Mittel	Sehr hoch

Profi-Tipp: Observability von Anfang einbauen, nicht als nachträgliche Ergänzung. Tools wie Prometheus und OpenTelemetry sollten ab Sprint 1 im Stack sein. Wer Monitoring nachrüstet, kämpft später blind gegen Produktionsprobleme.

Häufige Fehler bei wachsenden SaaS-Architekturen — und wie man sie vermeidet:

• Fehlende Domänengrenzen im Monolithen: Führt zu zyklischen Abhängigkeiten und macht spätere Extraktion nahezu unmöglich. Lösung: Domain-Driven Design als Strukturprinzip ab Tag eins.
• Frühzeitige Microservices ohne organisatorische Reife: Teams ohne klares Service-Ownership produzieren chaotische Microservices. Lösung: Erst Modulstruktur klären, dann extrahieren.
• Vendor Lock-in durch proprietäre Cloud-Services: Wer tief in AWS-Spezifika investiert, verliert Flexibilität. Lösung: Abstraktion über Modern Web Stack-Schichten und Infrastructure as Code.
• Fehlende Datenstrategie bei Skalierung: Multi-Tenant-Daten ohne Sharding-Strategie werden zum Performance-Problem. Lösung: Datenengineering und Analytics frühzeitig in die Architekturplanung integrieren.

Ein gut geplantes System vermeidet nicht alle Probleme, aber es macht sie beherrschbar — ohne alles neu aufbauen zu müssen.

---

Monolith First oder Microservices? Was wirklich zählt

Die Debatte ist so alt wie Microservices selbst. Und sie wird häufig falsch geführt. Denn die eigentliche Frage ist nicht »Monolith oder Microservices?«, sondern: »Was brauchen wir heute, und wie bereiten wir uns auf morgen vor?«

Ein hoher Anteil aller Softwareprojekte scheitert nicht an Implementierungsdetails, sondern an frühen Architekturfehlern. Das ist kein Qualitätsproblem, sondern ein Planungsproblem.

Der Modulith-First-Ansatz kombiniert die Einfachheit eines Monolithen mit der modularen Struktur, die eine spätere Migration zu Microservices vorbereitet. Metriken wie relationale Kohäsion machen die Entscheidung für oder gegen einen Service-Split objektiv messbar — statt sie dem Bauchgefühl zu überlassen.

Fitness Functions sind dabei ein unterschätztes Werkzeug. Sie messen kontinuierlich, ob die Architektur noch den definierten Qualitätszielen entspricht. Typische Metriken:

• Kohäsion: Gehören die Funktionen eines Moduls wirklich zusammen?
• Kopplung: Wie viele externe Abhängigkeiten hat ein Modul?
• Änderungsfrequenz: Welche Module ändern sich gemeinsam, obwohl sie getrennt sein sollten?

Woran man die geeignete Architektur für die aktuelle Phase erkennt:

1. Team-Größe und Service-Ownership: Gibt es klare Verantwortliche für einzelne Domänen? Ohne klares Ownership werden Microservices zum organisatorischen Chaos.
2. Deployment-Frequenz: Wenn mehrere Teams täglich deployen müssen — ohne voneinander abhängig zu sein —, spricht das für Service-Trennung.
3. Lastprofil einzelner Komponenten: Wenn ein einziges Modul 80 % der Last trägt, ist eigenständige Skalierung wirtschaftlich sinnvoll.
4. Regulatorische Anforderungen: Bei DSGVO-konformer Datentrennung oder Audit-Trails ist physische Trennung der Datenhaltung oft zwingend.
5. Budget und Betriebskapazität: Microservices erhöhen den DevOps-Aufwand erheblich. Ohne entsprechende Ressourcen entstehen neue Probleme.

Das Ergebnis ist immer eine kontextspezifische Entscheidung — ausgerichtet an messbaren Kriterien. Wer Architekturentscheidungen ohne diese Faktoren trifft, riskiert Over-Engineering in frühen Phasen oder Skalierungsprobleme in späteren.

---

Perspektive: Was Skalierbarkeit in SaaS wirklich verlangt

Die gängige Überzeugung in vielen Engineering-Teams lautet: Microservices bringen Flexibilität. Das stimmt — aber nur unter einer Bedingung: dass das Team, die Prozesse und die Infrastruktur reif genug dafür sind. In der Praxis begegnen uns immer wieder Teams, die zu früh in Microservices eingestiegen sind. Deren größtes Problem ist nicht das Produkt, sondern die Koordination zwischen zwölf Services ohne ausreichendes Monitoring.

Die unbequeme Wahrheit: Skalierbarkeit beginnt nicht mit der Wahl des richtigen Frameworks. Sie beginnt mit der ehrlichen Antwort auf die Frage, welche Probleme im nächsten Jahr tatsächlich auftreten werden. Wer das nicht weiß, sollte erst recht nicht mit Microservices starten.

Falsche Entscheidungen in frühen Phasen kosten exponentiell mehr im Scaling. Ein schlecht modularisierter Monolith, der nach 18 Monaten in 15 eng gekoppelte Services aufgeteilt wird, ist kein Fortschritt — es ist eine teure Neuauflage desselben Problems.

Was wirklich skaliert, sind Teams, die Metriken ernst nehmen, Feedback-Zyklen kurz halten und inkrementell bauen. Skaliert wird nie auf der grünen Wiese, sondern immer im laufenden Betrieb — mit realen Nutzern und echten Einschränkungen. Die Systeme, die diesen Weg erfolgreich gehen, haben eines gemeinsam: Sie wurden für Veränderung gebaut, nicht für den aktuellen Stand.

Offene Fehlerkultur und iteratives Engineering sind keine Soft Skills, sondern technische Voraussetzungen. Ein Team, das Architekturfehler versteckt, macht sie teurer. Ein Team, das sie offen benennt und iterativ behebt, baut langfristig bessere Systeme.

Das Plädoyer für einfache Lösungen ist kein Plädoyer für schlechte Architektur. Es ist der Hinweis, dass Komplexität immer einen konkreten Mehrwert rechtfertigen muss. Wer Komplexität einführt, ohne diesen Mehrwert zu benennen, hat kein Architektur-Problem, sondern ein Kommunikationsproblem.

---

Architekturberatung: Von der Vision zur mitwachsenden Realität

Die Frage, ob die eigene Architektur das nächste Wachstumsplateau trägt, ist schwer objektiv zu beantworten — wenn man selbst tief im System steckt. Genau dort setzt strukturierte Architekturberatung an: bevor Engpässe zum echten Problem werden und bevor der Rewrite-Trap zuschnappt.

H-Studio begleitet B2B-SaaS-Teams von der ersten Architekturentscheidung bis zur produktionsreifen Skalierung. Im Architecture Sprint (5 Tage, €3.500) erhalten Gründerteams vor dem MVP-Launch eine strukturierte Analyse der geplanten Architektur — inklusive konkreter Empfehlungen für Modulgrenzen, Skalierungsstrategien und DSGVO-Compliance. Wer bereits in einer Wachstumsphase ist, kann über den Projektplaner direkt einsteigen. Einen vollständigen Überblick aller Engineering-Leistungen bietet die Service-Übersicht.

---

Häufig gestellte Fragen zu Mitwachsenden Architekturen

Was ist der Unterschied zwischen mitwachsender Architektur und klassischem Scaling?

Mitwachsende Architekturen sind so entworfen, dass sie sich flexibel und schrittweise an Business-Wachstum anpassen. Klassische Skalierungsansätze setzen oft auf große, starre Umgestaltungen, die das System für Wochen destabilisieren können.

Wann ist der Umstieg auf Microservices sinnvoll?

Wenn organisatorische und technische Abhängigkeiten das weitere Wachstum behindern und einzelne Module unabhängig skaliert werden müssen. Der Übergang via Strangler-Fig-Pattern minimiert dabei das Risiko einer vollständigen Systemunterbrechung.

Wie lässt sich Vendor Lock-in verhindern?

Durch Multi-Cloud-Strategien und Infrastructure as Code lässt sich die Abhängigkeit von einzelnen Anbietern systematisch reduzieren — ohne auf Cloud-native Vorteile verzichten zu müssen.

Welche Metriken helfen bei der Architekturbewertung?

Fitness Functions wie Kohäsion und Kopplung geben objektive Orientierung bei der Architektur-Evolution und machen Entscheidungen für oder gegen einen Service-Split messbar — statt intuitiv.

Ab wann ist eine Architekturberatung sinnvoll?

Spätestens dann, wenn das Team feststellt, dass neue Features systematisch länger dauern als gleich große Features vor sechs Monaten. Das ist das früheste verlässliche Signal, dass die Architektur an ihre Grenzen kommt — und der beste Zeitpunkt für eine externe Sicht.

---

Weiterführend

• Skalierbare Softwarearchitektur · Architecture Sprint
• Engineering-Perspektiven · Kuratiert pro Fragestellung
• Enterprise-Engineering für Gründer & wachsende Teams
• Service-Übersicht · Was wir bauen