SaaS-Architektur: Entscheidungen, die Sie kaum rückgängig machen

Kurz gefasst: Bei einem SaaS-Produkt lassen sich die meisten Dinge später ändern, einige wenige aber kaum: das Modell der Mandantentrennung, die Struktur der Kerndaten, die Art der Benutzer- und Rechteverwaltung und der Ort, an dem die Daten liegen. Diese Entscheidungen sollten vor der ersten Zeile Produktcode bewusst getroffen werden. Fast alles andere, vom Framework bis zur Frage Microservices oder Monolith, können Sie mit gutem Gewissen pragmatisch halten.

Warum manche Architekturentscheidungen teuer werden

Software ist veränderbar, aber nicht überall gleich leicht. Eine Oberfläche umzubauen kostet ein paar Wochen. Die Art zu ändern, wie die Daten verschiedener Kunden voneinander getrennt sind, betrifft dagegen jede Abfrage, jede Datenbanktabelle und jeden Kunden, der bereits produktive Daten im System hat. Solche Änderungen werden mit jedem Monat Betrieb teurer, weil Migrationen echte Kundendaten betreffen und nicht ausfallen dürfen.

Die gute Nachricht: Die Liste der wirklich harten Entscheidungen ist kurz. Wer sie kennt, kann den Rest des Produkts schnell und iterativ entwickeln.

Mandantenfähigkeit: das Fundament jeder SaaS-Architektur

Mandantenfähigkeit (Multi-Tenancy) beschreibt, wie ein System die Daten vieler Kunden verwaltet. Es gibt drei gängige Modelle.

Gemeinsame Datenbank mit Mandanten-ID

Alle Kunden teilen sich Tabellen, jede Zeile trägt eine Mandanten-ID. Das ist günstig im Betrieb und einfach zu skalieren. Das Risiko liegt in der Disziplin: Eine einzige Abfrage ohne Mandantenfilter kann Daten eines Kunden einem anderen zeigen. PostgreSQL bietet mit Row-Level Security eine Absicherung direkt in der Datenbank, die solche Fehler abfängt.

Eigenes Schema pro Mandant

Jeder Kunde erhält ein eigenes Schema in derselben Datenbank. Die Trennung ist klarer, Migrationen müssen aber für jedes Schema einzeln laufen, was bei vielen Kunden mühsam wird.

Eigene Datenbank pro Mandant

Die stärkste Trennung, oft gefordert von Großkunden oder in regulierten Branchen. Dafür steigen Betriebsaufwand und Kosten deutlich. Ein verbreiteter Kompromiss ist ein gemeinsames Modell für die Mehrheit und eigene Datenbanken für einzelne Enterprise-Kunden, sofern die Architektur das von Beginn an vorsieht.

Das Datenmodell und die Datenbankwahl

Die Kernobjekte Ihres Produkts, etwa Kunden, Projekte, Verträge oder Buchungen, und ihre Beziehungen zueinander prägen das System auf Jahre. Für die meisten B2B-SaaS-Produkte ist eine relationale Datenbank wie PostgreSQL die sichere Wahl, weil Geschäftsdaten fast immer stark verknüpft sind und Transaktionen brauchen. Dokumentendatenbanken haben ihre Stärken, sind als Hauptspeicher für klassische Geschäftsprozesse aber seltener die bessere Wahl. Eine ausführlichere Abwägung finden Sie im Datenbank-Vergleich PostgreSQL vs. MongoDB.

Planen Sie außerdem früh, wie sich Schemaänderungen im laufenden Betrieb einspielen lassen. Versionierte Migrationen gehören vom ersten Tag an ins Projekt.

Authentifizierung, Rollen und Rechte

Wie sich Nutzer anmelden und was sie dürfen, wirkt auf den ersten Blick wie ein Detail. In der Praxis fragen B2B-Kunden schnell nach Single Sign-on über ihren eigenen Identitätsanbieter, nach Rollen mit unterschiedlichen Berechtigungen und nach Nutzern, die mehreren Organisationen angehören. Wer zu Beginn nur "ein Nutzer, ein Konto, ein Passwort" vorsieht, baut das später unter Schmerzen um.

Es lohnt sich, die Benutzerverwaltung entweder über einen etablierten Identitätsdienst zu lösen oder von Anfang an mit Organisationen, Mitgliedschaften und Rollen zu modellieren. Die technischen Grundlagen erklären wir in Authentifizierung mit OAuth, JWT und Sessions.

Hosting, Datenstandort und Abhängigkeiten

Für deutsche und europäische Geschäftskunden ist der Speicherort der Daten oft ein Kaufkriterium. Ein späterer Umzug von einem US-Rechenzentrum in die EU ist möglich, aber aufwendig und mit Risiken für den Betrieb verbunden. Wählen Sie die Region daher bewusst. Warum das für viele Kunden zählt, beschreibt unser Artikel zu Hosting in Deutschland.

Achten Sie ebenso darauf, wie tief Sie sich an proprietäre Dienste eines Cloud-Anbieters binden. Verwaltete Datenbanken und Speicher sind sinnvoll. Wenn aber Geschäftslogik nur noch in anbieterspezifischen Funktionen lebt, wird ein Wechsel praktisch unmöglich.

Was Sie getrost offen lassen können

Viele Teams verbringen zu viel Zeit mit Fragen, die sich später gut ändern lassen. Dazu gehört die Aufteilung in Microservices: Ein sauber strukturierter Monolith trägt die meisten SaaS-Produkte weit. Auch Caching-Strategien, das Frontend-Framework im Detail oder die Wahl des Deployment-Werkzeugs lassen sich nachjustieren, wenn echte Nutzung zeigt, wo es hakt.

Häufige Fragen (FAQ)

Welches Mandantenmodell passt zu einem neuen SaaS-Produkt?

Für die meisten neuen Produkte ist die gemeinsame Datenbank mit Mandanten-ID und Row-Level Security der beste Start. Sie hält Kosten und Betrieb schlank. Wichtig ist, die Mandanten-ID konsequent überall mitzuführen, damit ein späterer Wechsel zu getrennten Datenbanken für einzelne Kunden möglich bleibt.

Sollte ein SaaS von Anfang an auf Microservices setzen?

In der Regel nicht. Microservices lösen Probleme großer Teams und sehr unterschiedlicher Lastprofile. Für ein junges Produkt erhöhen sie vor allem den Betriebsaufwand. Ein modularer Monolith lässt sich später entlang klarer Grenzen aufteilen.

Wie wichtig ist der Serverstandort für deutsche B2B-Kunden?

Für viele sehr wichtig, besonders bei personenbezogenen Daten und in regulierten Branchen. Hosting in der EU vereinfacht die DSGVO-Dokumentation und beantwortet eine Frage, die in fast jedem Einkaufsprozess gestellt wird.

Kann man diese Entscheidungen später korrigieren?

Ja, aber zu einem hohen Preis. Jede Änderung am Mandantenmodell oder an der Benutzerstruktur betrifft bestehende Kundendaten und braucht sorgfältige Migrationen ohne Ausfallzeit. Deshalb lohnt sich ein halber Tag Planung mehr am Anfang.

Fazit

Eine gute SaaS-Architektur entsteht, wenn Sie die wenigen schwer umkehrbaren Punkte ernst nehmen und den Rest bewusst einfach halten. Mandantentrennung, Datenmodell, Rechteverwaltung und Datenstandort verdienen Zeit, das meiste andere darf mit dem Produkt wachsen.

Wenn Sie eine SaaS-Plattform planen und diese Entscheidungen mit erfahrenen Entwicklern durchgehen möchten, sprechen Sie mit uns über Webentwicklung für SaaS-Produkte.