Für ein frühes B2B-SaaS ist „Microservices ab Tag eins“ selten die vernünftige Standardentscheidung. Sinnvoller ist meist ein modulares System mit klaren Mandantengrenzen, getestetem Datenlebenszyklus, automatisierter Auslieferung, wiederherstellbarer Infrastruktur und genug Observability für Entscheidungen auf Basis realer Daten. Für viele Seed- und Early-Growth-Teams bedeutet das: modularer Monolith auf Managed Infrastructure. Komponenten werden erst dann extrahiert, wenn Last, Ownership oder Zuverlässigkeitsanforderungen den zusätzlichen Betriebsaufwand rechtfertigen.
Produktionsreife ist damit kein Tech-Stack, sondern nachweisbare Systemeigenschaft: Ein Tenant kann nicht auf Daten eines anderen zugreifen, ein fehlerhaftes Release lässt sich beherrschen, Backups können wiederhergestellt werden, Berechtigungen sind testbar, Vorfälle werden sichtbar und personenbezogene Daten lassen sich entsprechend dokumentierter rechtlicher und vertraglicher Anforderungen behandeln.
Dieser Leitfaden bündelt die bisherigen H-Studio-Texte zu SaaS-Skalierung, Multi-Tenancy, DSGVO, Auditierbarkeit und Launch Readiness in einem Entscheidungsrahmen für Gründer:innen und CTOs im DACH-Raum.
Inhaltsverzeichnis
- Der kurze Entscheidungsrahmen
- Sechs später schwer änderbare Entscheidungen
- Modularer Monolith oder Microservices?
- Tenant-Isolation bewusst wählen
- DSGVO in Systemanforderungen übersetzen
- Production-Readiness mit Gates prüfen
- An gemessenen Engpässen skalieren
- Eine praktische Roadmap
- Häufige Fragen
Der kurze Entscheidungsrahmen
| Produktsituation | Sinnvoller Default | Nachweis vor zusätzlicher Komplexität |
|---|---|---|
| Vor PMF oder erste zahlende Kunden | Modularer Monolith, Managed Database, eine Delivery-Pipeline | Klare Domänengrenzen, Tenant-Tests, Backups und grundlegende Observability |
| Mehrere Kundensegmente oder Enterprise Procurement | Rollenmodell, Audit-Trails, automatisierter Datenlebenszyklus und dokumentierte Unterauftragnehmer | Konkrete Käuferanforderungen und Threat Model |
| Stark unterschiedliche Tenant-Last | Tenant-Metriken, Quotas, Job-Isolation und Kapazitätsgrenzen | P95/P99-Latenz, Queue-, Datenbank- und Kostendaten pro Tenant |
| Unabhängige Produktteams | Nur Domänen mit eigener Ownership oder Release-Frequenz extrahieren | Stabile Grenze, benannte Owner und Runbook |
| Regulatorisch oder vertraglich geforderte Isolation | Separates Schema, Datenbank oder Konto, soweit die Anforderung es rechtfertigt | Schriftliches Kontrollziel und getestete Migration/Wiederherstellung |
Die Reihenfolge ist entscheidend. Einen weiteren Service, eine Queue oder einen Cluster kann man später ergänzen. Ein unklares Tenant-Modell, inkonsistente Berechtigungen oder ein nicht dokumentierter Datenlebenszyklus lassen sich nach den ersten Enterprise-Kunden nur mit deutlich höherem Risiko korrigieren.
Sechs später schwer änderbare Entscheidungen
1. Tenant-Identität und Isolation
Definieren Sie, wie der Tenant-Kontext ermittelt, geprüft und durch HTTP-Requests, Hintergrundjobs, Caches, Object Storage und Analytics geführt wird. Eine vom Client gesendete Tenant-ID ist noch kein vertrauenswürdiger Kontext. Sie muss aus einer authentifizierten Beziehung abgeleitet und die Ownership am Datenzugriff erneut geprüft werden.
Die OWASP-Empfehlungen für Multi-Tenant Security behandeln Isolation folgerichtig als systemweite Aufgabe: Datenbankzeilen, Cache-Keys, Dateipfade, Queues, Logs sowie Onboarding und Offboarding brauchen Tenant-Kontext. Eine tenant_id-Spalte allein ist keine vollständige Isolationsstrategie.
2. Identitäten, Rollen und Sonderzugriffe
„Admin“ ist für B2B-Software selten ein ausreichendes Rollenmodell. Plattform-Operatoren, Tenant-Administratoren und Endnutzer brauchen getrennte Rechte. Legen Sie fest, wie Support-Zugriff genehmigt, zeitlich begrenzt und protokolliert wird. Verbotene Pfade müssen ebenso systematisch getestet werden wie erlaubte.
3. Datenverantwortung und Lebenszyklus
Erstellen Sie eine Datenlandkarte, bevor Kundendaten über Hauptdatenbank, Suche, Object Storage, Analytics, CRM und Backups verteilt sind. Für jede Datenklasse gehören Zweck, Owner, Aufbewahrung, Export und Löschverhalten dokumentiert. Offboarding ist ein Architektur-Flow, kein manuelles Ticket am Vertragsende.
4. Domänen- und API-Grenzen
Module sollten Geschäftsfähigkeiten wie Identity, Billing, Workflow oder Reporting abbilden — nicht technische Ordner wie Controller und Repository. Explizite Schnittstellen zwischen Modulen halten das erste Deployment einfach und schaffen einen belastbaren Weg für spätere Extraktion.
5. Delivery und Recovery
Jede Produktionsänderung braucht Owner, automatisierte Checks, einen kontrollierten Deployment-Pfad und eine Recovery-Entscheidung. „Wir machen Backups“ ist erst dann belastbar, wenn ein Restore in einer produktionsnahen Umgebung funktioniert hat. Datenbankmigrationen brauchen Forward- sowie Repair/Recovery-Strategien; ein Code-Rollback macht eine inkompatible Datenänderung nicht automatisch rückgängig.
6. Observability und Kostenzuordnung
Globale Durchschnittswerte verstecken den einen Kunden, dessen Workflow ausfällt. Metriken sollten Tenant- und Workflow-Kontext enthalten, ohne sensible Daten in Logs zu schreiben. Relevant sind Tail Latency, Fehlerraten, Queue-Verzögerung und Ressourcenverbrauch. Bei geteilter Infrastruktur müssen Kosten und Noisy-Neighbor-Effekte sichtbar sein, bevor eine Architekturmaßnahme gewählt wird.
Modularer Monolith oder Microservices?
| Modell | Guter Einsatz | Hauptrisiko |
|---|---|---|
| Einfacher Monolith | Kurzlebiger Prototyp mit schmaler Domäne | Grenzen bleiben implizit, jede Änderung berührt alles |
| Modularer Monolith | Die meisten frühen B2B-SaaS-Produkte und kleine Produktteams | Module existieren nur auf Folien, wenn Abhängigkeiten nicht erzwungen werden |
| Microservices | Domänen mit unabhängiger Ownership, Skalierung oder Reliability | Verteilte Delivery, Datenkonsistenz und Observability werden zu eigener Produktarbeit |
Ein modularer Monolith ist ein deploybares System mit durchgesetzten Domänengrenzen. Er ist kein Versprechen, dass aller Code für immer zusammenbleibt. Transaktionen, lokale Entwicklung und Deployment bleiben verständlich, während das Team noch lernt, was das Produkt tatsächlich ist.
Ein Modul sollte erst extrahiert werden, wenn mindestens ein konkreter Druck besteht:
- Es braucht ein anderes Skalierungsprofil und der Engpass ist gemessen.
- Ein Team benötigt unabhängige Ownership und Release-Kontrolle.
- Ein Ausfall muss vom Kernworkflow isoliert werden.
- Eine Sicherheits- oder Vertragsgrenze erfordert separate Infrastruktur.
- Das Modul hat eine stabile Schnittstelle und einen Runbook-Owner.
Extrahieren Sie nicht nur deshalb, weil das Framework einen neuen Service schnell erzeugt. Die teure Arbeit beginnt danach: versionierte Schnittstellen, Deployment-Koordination, Retries, Tracing, Datenverantwortung und On-Call-Betrieb.
Tenant-Isolation bewusst wählen
| Modell | Isolation | Betriebsaufwand | Typischer Einsatz |
|---|---|---|---|
| Gemeinsame Tabellen („Pool“) | Logisch, meist über Tenant-Key und Policies | Niedrig | Viele Tenants mit ähnlichen Anforderungen |
| Separate Schemas | Stärkere Namespace-Trennung | Mittel | Kleinere Tenant-Zahl oder differenzierter Betrieb |
| Separate Datenbanken/Konten („Silo“) | Starke Infrastrukturgrenze | Hoch | Vertraglich, regulatorisch oder risikobedingt hohe Isolation |
| Hybrid | Tarif- oder kundenspezifisch | Höhere Produktkomplexität | Standard-Pool plus dedizierter Enterprise-Tier |
PostgreSQL Row-Level Security kann erzwingen, welche Zeilen normale Datenbankrollen lesen oder verändern dürfen. Die offizielle PostgreSQL-Dokumentation nennt aber eine wichtige Einschränkung: Superuser und Rollen mit BYPASSRLS umgehen Policies; Table Owner tun das normalerweise ebenfalls, sofern RLS nicht erzwungen wird. RLS ist deshalb Defense in Depth. Die Anwendung sollte mit einer geeigneten Non-Owner-Rolle laufen, ergänzt durch Tenant-Prüfungen und Regressionstests.
Isolation umfasst außerdem:
- Cache-Keys und Suchindizes;
- Datei-/Object-Storage-Pfade und Signed URLs;
- Hintergrundjobs und Message-Payloads;
- Analytics-Exporte und Support-Tools;
- Rate Limits und Ressourcenquoten;
- Provisionierung, Sperrung, Export und Löschung eines Tenants.
Das beste Modell ist das einfachste, das tatsächliches Risiko und Vertrag erfüllt. Separate Datenbanken bieten eine starke Grenze, vervielfachen aber Migrationen, Backups, Monitoring und Kosten. Ein Shared-Modell ist effizient, sofern Kontrollen systematisch durchgesetzt und getestet werden.
DSGVO in Systemanforderungen übersetzen
Dieser Abschnitt ist eine Engineering-Einordnung und keine Rechtsberatung. Rollen, Rechtsgrundlage und Dokumentation müssen für das konkrete Produkt und die jeweilige Verarbeitung geprüft werden.
Die DSGVO macht Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen in Art. 25 ausdrücklich zum Thema. Art. 32 behandelt die dem Risiko angemessene Sicherheit, Art. 28 Auftragsverarbeitung, Art. 35 die Datenschutz-Folgenabschätzung bei voraussichtlich hohem Risiko und Kapitel V die Übermittlung personenbezogener Daten in Drittländer. Die Leitlinien 4/2019 des Europäischen Datenschutzausschusses konkretisieren Art. 25.
Übersetzen Sie diese Fragen in den Product Backlog:
| Rechtliche/vertragliche Frage | Konsequenz im System |
|---|---|
| Welche personenbezogenen Daten werden wofür verarbeitet? | Dateninventar, Zweckkennzeichnung und Owner |
| Wer ist Verantwortlicher oder Auftragsverarbeiter? | Passende Verträge, Zuständigkeiten und Request-Flows |
| Wie lange werden Daten benötigt? | Durchgesetzte Retention- und Löschjobs |
| Wie werden Auskunft und Löschung bearbeitet? | Durchsuchbares Inventar, Export und verifizierter Löschablauf |
| Welche Unterauftragnehmer und Regionen sind beteiligt? | Anbieterregister, Datenflussdiagramm und Deployment-Kontrollen |
| Welche Sicherheit ist dem Risiko angemessen? | Threat Model, Zugriffsschutz, Verschlüsselung, Recovery und Evidenz |
| Ist eine risikoreiche Verarbeitung geplant? | DSFA-Entscheidung und gegebenenfalls Prüfung vor Launch |
Die DSGVO verlangt nicht pauschal, dass alle Daten in Deutschland oder der EU gehostet werden. EU-Hosting kann Transferkomplexität und Procurement-Reibung reduzieren. Entscheidend ist aber der vollständige Datenfluss — einschließlich Support-Zugriff, Telemetrie, Unterauftragnehmern und Backups — und nicht allein die Region der Hauptdatenbank.
Auch ein Zertifikat ersetzt keine Produktkontrollen. ISO 27001, BSI C5, SOC 2 oder TISAX können für bestimmte Käufer relevant sein, doch Bedeutung, Scope und Aufwand hängen von Markt und Kontrollziel ab. Statt alle Zertifizierungen pauschal einzuplanen, sollte geklärt werden, welche Nachweise der Zielkunde wirklich verlangt.
Production-Readiness mit Gates prüfen
Jedes Gate braucht Evidenz und eine verantwortliche Person.
| Gate | Mindestnachweis vor Launch |
|---|---|
| Tenant-Isolation | Automatisierte Cross-Tenant-Tests für API, Jobs, Cache und Dateien |
| Identity & Permissions | Rollenmatrix, Denied-Path-Tests, Session-/Token-Ablauf |
| Delivery | Reproduzierbarer Build, automatisierte Checks, kontrolliertes Production-Deployment |
| Datenbankänderung | Getestete Migration auf produktionsnahem Volumen plus Repair/Recovery-Plan |
| Recovery | Erfolgreicher Restore mit dokumentierter Recovery Time und Owner |
| Observability | Workflow- und Tenant-Metriken, getesteter Alert, Eskalationsweg |
| Security | Threat Model, Dependency-/Secret-Handhabung, priorisierte Findings |
| Datenlebenszyklus | Datenkarte, Retention, Export-/Löschtest, Unterauftragnehmerregister |
| Operations | Runbooks für Incident, Rollback, Tenant-Sperrung und Offboarding |
Vermeiden Sie universelle Zahlen wie „80 Prozent Test Coverage“ oder „dreifache erwartete Last“. Solche Werte können interne Ziele sein, beweisen aber keine Produktionsreife. Ein Produkt mit hoher Line Coverage kann die Tenant-Grenze ungetestet lassen. Ein Lasttest ist nur dann aussagekräftig, wenn Workload, Service-Ziel und erwartetes Wachstum klar sind.
Für Datenschutzverletzungen enthält Art. 33 DSGVO eine 72-Stunden-Frist zur Meldung an die Aufsichtsbehörde, soweit die Meldepflicht greift. Die Engineering-Konsequenz ist nicht „jeden Alert melden“, sondern Evidenz zu erhalten, einen Bewertungs- und Eskalationsprozess zu definieren und verantwortliche Personen erreichbar zu machen.
An gemessenen Engpässen skalieren
Skalierung ist eine Folge gezielter Änderungen, keine Migration auf eine modische Plattform.
- Nutzerrelevanten Workflow messen. Service-Ziele für die Pfade definieren, die Kunden tatsächlich brauchen.
- Engpass lokalisieren. Datenbank, Anwendung, Queue, Netzwerk und Drittanbieter-Latenz trennen.
- Verschwendung vor Kapazität beheben. N+1 Queries, übergroße Payloads, doppelte Jobs und fehlende Indizes korrigieren.
- Gezielten Mechanismus ergänzen. Stabilen Read cachen, langsame Arbeit in eine Queue legen, Read Replica hinzufügen oder einen Workload isolieren.
- Fehlerbild und Kosten erneut prüfen. Mehr Komponenten können Durchsatz erhöhen und gleichzeitig Recovery oder Kosten verschlechtern.
Kubernetes, Redis, Queues und Read Replicas sind Optionen, keine Reifeabzeichen. Managed Services reduzieren Betriebsarbeit, doch jede Komponente braucht weiterhin Ownership, Backup, Monitoring und ein bekanntes Fehlerbild.
Bei Multi-Tenant-Produkten wird häufig die Control Plane wichtig, bevor rohe Compute-Skalierung nötig ist. Onboarding, Konfiguration, Entitlements, Quotas, Custom Domains, Migrationen und Offboarding brauchen konsistente Automatisierung. Sonst erzeugt Wachstum einen Operations-Stau, obwohl die Anwendung selbst schnell bleibt.
Eine praktische Roadmap
Stufe 1: Fundament
- Domänengrenzen und Architecture Decision Records etablieren;
- Tenant-Kontext, Rollen und Datenverantwortung definieren;
- Build, Tests und Deployment automatisieren;
- Backups, Restore-Tests und grundlegende Observability einführen;
- realen Datenfluss und Unterauftragnehmer dokumentieren.
Stufe 2: Produktionsreife
- kritische Nutzer- und Tenant-Grenzen als Regressionstests abbilden;
- Migrationen und Recovery mit produktionsnahen Volumen testen;
- Runbooks, Alert-Ownership und Incident-Bewertung ergänzen;
- Tenant-Lifecycle-Operationen automatisieren;
- Anforderungen des ersten Enterprise Buying Centers validieren.
Stufe 3: Evidenzbasierte Skalierung
- Service-Indikatoren pro Tenant und Workflow ergänzen;
- Quotas und Workload-Isolation bei nachgewiesener Konkurrenz einführen;
- nur stabile Domänen mit benanntem Betriebs-Owner extrahieren;
- Architektur, Datenschutzkontrollen und Kosten nach wesentlichen Produktänderungen prüfen.
Ein Architektur-Sprint kann diese Fragen vor einem größeren Build in Systemkarte, Risikoregister und phasenweisen Umsetzungsplan übersetzen. Bei einer bestehenden Plattform sollte die Analyse mit beobachteten Engpässen und Incidents beginnen — nicht mit einem bereits beschlossenen Rewrite.
Häufige Fragen
Muss ein MVP schon skalierbar sein?
Es braucht einen belastbaren Weg zur Skalierung, nicht maximale Infrastruktur. Schützen Sie die schwer änderbaren Entscheidungen — Tenant-Isolation, Datenmodell, Berechtigungen, Lebenszyklus und Modulgrenzen — und halten Sie Deployment und Betrieb zunächst einfach.
Ist ein modularer Monolith nur eine Übergangsarchitektur?
Nein. Er kann langfristig eine wirksame Produktionsarchitektur bleiben. Sein Wert liegt in expliziten Domänengrenzen, sodass ausgewählte Module bei realem Ownership-, Reliability- oder Skalierungsdruck extrahiert werden können.
Verlangt die DSGVO EU-Hosting?
Nicht pauschal. Die DSGVO regelt Verarbeitung und internationale Übermittlungen. EU-Hosting kann Risiko und Procurement vereinfachen, aber Support-Zugriff, Telemetrie, Unterauftragnehmer und Backup-Standorte müssen weiterhin geprüft werden.
Reicht PostgreSQL RLS für Tenant-Isolation?
Nein. RLS ist eine starke Datenbankkontrolle, braucht aber passende Rollen, Application Authorization, Tenant-scoped Cache/Storage/Jobs und Regressionstests. Besondere Aufmerksamkeit verdienen DB-Owner und Rollen mit Bypass-Rechten.
Wann sollte ein SaaS-Team Microservices einführen?
Wenn eine stabile Domäne unabhängige Ownership, Deployment, Reliability oder Skalierung benötigt und das Team den verteilten Betrieb tragen kann. Teamgröße, ARR oder Produktalter allein sind schlechte Trigger.
Was sollte quartalsweise geprüft werden?
Wesentliche Änderungen der Datenflüsse, Unterauftragnehmer, Berechtigungen, Restore-Evidenz, Incident-Erkenntnisse, Tenant-Isolationstests, Service-Ziele, Kostenkonzentration und nicht mehr gültige Architekturentscheidungen.
Nächste Schritte
- SaaS-MVP-Entwicklung — eine produktionsorientierte erste Version planen und bauen
- Backend-Entwicklung — Domänengrenzen, APIs und Datenflüsse stärken
- DevOps & Cloud Engineering — Delivery, Observability und Recovery
- Architektur-Sprint — System- und Risikoprüfung mit festem Scope vor der Umsetzung
Überarbeitet und konsolidiert von Anna Hartung am 15. Juli 2026. Rechtliche Anforderungen sind für das konkrete Produkt und den Verarbeitungskontext gesondert zu prüfen.
