Mandantenfähige SaaS bauen: Architekturentscheidungen

Eine mandantenfähige SaaS bedient viele Kunden (Mandanten) aus einem Produkt. Gut umgesetzt betreiben Sie eine Codebasis, deployen einmal, und jeder Kunde profitiert von jeder Verbesserung. Schlecht umgesetzt sieht ein Kunde die Daten eines anderen, ein großer Kunde bremst alle anderen aus, oder jeder Enterprise-Auftrag wird zu einem eigenen Fork des Codes.

Die meisten dieser Ergebnisse entscheiden sich früh, in einer Handvoll Architekturentscheidungen. Hier sind die, die wir mit Kunden durchgehen, und was wir beim Bau standortübergreifender Plattformen wie Smart DigiBuild gelernt haben, die wir für Four Corners Technology entwickeln.

1. Wie die Daten der Mandanten getrennt werden

Es gibt drei verbreitete Modelle:

• Gemeinsame Datenbank, gemeinsame Tabellen: Jede Zeile trägt eine Mandanten-ID. Am günstigsten und am einfachsten zu betreiben, aber die Trennung hängt davon ab, dass jede Abfrage richtig filtert.
• Gemeinsame Datenbank, eigenes Schema pro Mandant: bessere Trennung und einfacherer Export pro Mandant, dafür aufwendigere Migrationen, je mehr Mandanten es gibt.
• Eigene Datenbank pro Mandant: stärkste Trennung und einfache Sicherung, Wiederherstellung und Datenresidenz pro Mandant, aber höhere Kosten und mehr Betriebsaufwand.

Für die meisten B2B-Produkte beginnen wir mit gemeinsamen Tabellen und Mandanten-ID, abgesichert auf Datenbankebene, etwa mit Row-Level Security in PostgreSQL, sodass ein vergessener Filter im Code keine Daten preisgibt. Große oder regulierte Kunden können später eine eigene Datenbank erhalten. Gestalten Sie den Code von Anfang an so, dass das möglich ist: Mandantenzugriff läuft über eine Datenzugriffsschicht, nie über verstreute Einzelabfragen.

2. Woher der Mandantenkontext kommt

Jede Anfrage muss wissen, zu welchem Mandanten sie gehört. Typische Quellen sind die Subdomain (kunde.app.de), ein Claim im Login-Token oder ein expliziter Mandantenwechsel für Nutzer, die zu mehreren Organisationen gehören. Ermitteln Sie den Mandanten einmal, früh in der Anfrage, und reichen Sie ihn explizit weiter. Hintergrundjobs, Queues, Caches, Dateispeicher und Suchindizes brauchen den Mandanten ebenfalls. Cache-Schlüssel und Speicherpfade ohne Mandantenpräfix sind eine klassische Quelle für Datenlecks.

3. Authentifizierung und Rollen

B2B-Kunden erwarten mehr als E-Mail und Passwort:

• Organisationen und Rollen: Admins laden Nutzer ein, vergeben Rollen und entfernen Ausgeschiedene selbst.
• Single Sign-on: Größere Kunden wollen sich mit Microsoft Entra ID, Google oder ihrem eigenen Identity Provider per SAML oder OpenID Connect anmelden.
• Audit-Logs: wer was wann geändert hat, sichtbar für die Admins des Kunden.

Nutzen Sie einen etablierten Identity-Dienst oder eine Bibliothek, statt das selbst zu bauen, und modellieren Sie Rollen von Anfang an pro Mandant.

4. Konfiguration statt Sondercode

Jeder Kunde wird etwas leicht anderes wollen. Wenn jeder Wunsch zu einer if-Abfrage mit Kundennamen wird, ist das Produkt bald nicht mehr wartbar. Planen Sie Konfiguration ein:

• Feature Flags pro Mandant und pro Tarif.
• Einstellungen für Abläufe, Felder, Benachrichtigungen und Branding.
• Erweiterungspunkte wie Webhooks und eine API, damit Kunden integrieren können, ohne den Kern zu ändern.

Unsere Regel: Brauchen es zwei Kunden, wird es eine konfigurierbare Funktion. Braucht es nur einer, suchen wir zuerst eine Integration.

5. Tarife, Limits und Abrechnung

Entscheiden Sie früh, wie Sie abrechnen: pro Nutzer, pro Standort, nach Verbrauch oder pauschal pro Tarif. Das Produkt muss dann den Tarif jedes Mandanten kennen, Limits durchsetzen (Nutzer, Geräte, Speicher, API-Aufrufe) und Verbrauch messen. Zahlungsanbieter wie Stripe übernehmen Rechnungen und Abonnements, aber Limits und Verbrauchsmessung gehören in Ihr Produkt.

6. Laute Nachbarn

In einem geteilten System kann der große Import oder der schwere Bericht eines Mandanten alle anderen ausbremsen. Schützen Sie sich mit Rate Limits pro Mandant, Hintergrund-Queues für aufwendige Arbeit, Zeitlimits für Abfragen und Monitoring, das die Last pro Mandant zeigt. Braucht ein Mandant dauerhaft deutlich mehr, ist das ein Grund, ihn auf eigene Ressourcen zu verlegen, idealerweise als höherpreisiger Tarif.

7. Datenresidenz und Compliance

Deutsche und europäische Kunden fragen oft, wo ihre Daten liegen, wer darauf zugreifen kann und wie sie gelöscht werden. Beantworten Sie das in der Architektur:

• Hosting in einer EU-Region und dokumentierte Unterauftragsverarbeiter.
• Ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) für jeden Kunden.
• Export und Löschung pro Mandant, um Auskunfts- und Löschanfragen zu erfüllen und das Vertragsende abzuwickeln.
• Backups mit festgelegter Aufbewahrung und eine getestete Wiederherstellung für einzelne Mandanten.

8. Migrationen und Releases

Mit einer Codebasis für alle trifft ein fehlerhaftes Release jeden Kunden gleichzeitig. Nutzen Sie abwärtskompatible Datenbankmigrationen (erst erweitern, später zurückbauen), automatisierte Tests einschließlich Tests der Mandantentrennung, schrittweise Rollouts mit Feature Flags und ein schnelles Rollback. Bei eigenen Datenbanken pro Mandant automatisieren Sie Migrationen über alle hinweg und überwachen deren Fortschritt.

9. Beobachtbarkeit pro Mandant

Logs, Metriken und Traces sollten die Mandanten-ID tragen. Dann beantwortet der Support die Frage „Warum ist es bei Kunde X langsam?“ in Minuten, Sie sehen, welche Mandanten welche Funktionen nutzen, und Sie bemerken, wenn bei einem Mandanten nach einem Release Fehler auftreten.

Fazit

Mandantenfähigkeit ist kein Feature, das man später ergänzt. Datentrennung, Mandantenkontext, Rollen, Konfiguration, Limits und Compliance prägen die Codebasis ab dem ersten Sprint. Wer sie früh richtig angeht, behält eine Codebasis, auch wenn Kunden und ihre Wünsche wachsen. Wir konzipieren und entwickeln mandantenfähige B2B-Plattformen, vom MVP bis zur Skalierung. Mehr zu unserer individuellen Softwareentwicklung oder dazu, wie Sie ein MVP in 8 Wochen starten.

SaaS-Architektur besprechen