Multi-Tenant SaaS · Entscheidungen, die man teuer bezahlt
Sechs Architektur-Entscheidungen am Anfang eines SaaS-Produkts, die später nicht mehr revidierbar sind.
SaaS-Produkte scheitern selten an einzelnen Features. Sie scheitern an frühen Architektur-Entscheidungen, die sich zwei oder drei Jahre später als nicht mehr rückführbar herausstellen. Wer schon einmal versucht hat, ein produktives Multi-Tenant-System von Shared-Schema auf Isolated-Schema zu migrieren, weiß, was gemeint ist.
Die folgenden sechs Entscheidungen betreffen den Kern jeder SaaS-Architektur. Sie sollten am Anfang bewusst getroffen werden, nicht implizit im ersten Sprint entstehen.
Tenant-Isolation · Shared vs. Isolated Schema.
Shared-Schema ist einfacher, günstiger und tragfähig für mittelgroße SaaS. Isolated-Schema ist teurer im Betrieb, aber zwingend bei streng regulierten Kunden oder wenn Tenants sehr unterschiedliche Datenmodell-Erweiterungen benötigen.
Die Fehlwahl ist selten „Shared", sondern „Wir entscheiden später." Wer die Entscheidung nicht trifft, produziert unfreiwillig ein Shared-Schema, das später nicht mehr trennbar ist. Wenn eine spätere Isolation absehbar sein könnte, muss der Datenzugriff von Anfang an so gebaut sein, dass die Tenant-Grenze im Datenmodell explizit sichtbar ist.
Auth · Wer definiert Identity.
Die Wahl zwischen selbst gebauter Authentifizierung, einem Auth-Dienst (Auth0, Clerk, WorkOS) und einem Enterprise-Identity-Provider (SAML, OIDC gegen Kunden-Systeme) ist keine Detail-Entscheidung. Sie prägt den Enterprise-Fit des Produkts.
Eigenbau ist oft die kürzeste Antwort im Prototyp und der längste Weg in die Zukunft. Ein Auth-Dienst kostet, gibt aber SSO, MFA und Compliance-Zertifikate ohne Eigenaufwand. Enterprise-SSO ist ein Muss, sobald ein Kunde mit mehr als 100 Nutzern auftritt.
Datenmodell · Wie hart ist das Schema.
Ein starres Datenmodell ist schneller zu bauen und schwerer zu pflegen, wenn Tenants unterschiedliche Felder brauchen. Ein zu flexibles Datenmodell (Key-Value-Overloading, EAV) ist schwer zu abfragen und produziert langsame Reports.
Ein pragmatischer Kompromiss: strenges Kernschema mit klar definierten Erweiterungspunkten pro Tenant. Wichtige Daten bleiben normalisiert und schnell auswertbar. Optionale Zusatzfelder liegen in gut typisierten Erweiterungstabellen.
Rechte · Rollen vs. Berechtigungen.
Ein rein rollenbasiertes Modell (RBAC) ist einfach, wird aber schnell unflexibel, sobald ein Kunde eigene Rollen benötigt. Ein rein berechtigungsbasiertes Modell (ABAC) ist flexibel, aber schwer verständlich für Betriebe ohne IT-Abteilung.
In der Praxis trägt ein hybrider Ansatz: fest definierte Rollen pro Tenant, jede Rolle als Bündel klar benannter Berechtigungen. Neue Rollen sind eine Kombination bestehender Berechtigungen. So bleibt das System für den Kunden verständlich und für uns wartbar.
Billing · Von der ersten Zeile Code aus.
Billing wird oft am Ende eingebaut. Das ist der Grund, warum Preisänderungen später so schmerzhaft sind. Wenn Nutzung, Nutzer, Ressourcen oder Speicher-Verbrauch verrechnet werden sollen, muss die Zählung vom ersten Tag an sauber laufen.
Ein guter Ansatz: eine klar getrennte Metering-Ebene, die alle relevanten Ereignisse aggregiert (Nutzer-Anmeldungen, API-Aufrufe, Speicher, Feature-Nutzung). Die Preisgestaltung sitzt darüber und ist austauschbar. So kann das Pricing-Modell sich ändern, ohne dass die Anwendung sich ändern muss.
Deployment · Wie viele Umgebungen wirklich.
Ein produktives SaaS braucht typischerweise mehr Umgebungen, als am Anfang gedacht: mindestens Preview, Staging und Production, oft dazu ein Sandbox-Bereich für Kunden. Wer das später nachbaut, migriert schmerzhaft.
Zusätzlich zur Umgebungszahl entscheidet die Deployment- Strategie über den Betrieb: containerisiert auf einer eigenen Cloud (AWS, Azure) oder auf einer Plattform (Vercel, Fly). Die Wahl hängt vom Nutzungsprofil, den Compliance-Anforderungen und der Team-Struktur ab. Sie ist selten „einmal für alle".
Zum Thema.
- Können solche Entscheidungen später korrigiert werden?
- Teilweise. Auth, Deployment und Rechte-Modell lassen sich mit erheblichem Aufwand austauschen. Tenant-Isolation und Datenmodell sind nach ein bis zwei Jahren produktiven Betriebs meist nicht mehr sauber revidierbar. Deshalb gehören sie an den Anfang.
- Wie lange dauert ein sauberer SaaS-Kern?
- Für einen produktiven SaaS-Kern rechnen wir typischerweise 12 bis 20 Wochen, abhängig davon, wie viele der oben genannten Entscheidungen sofort komplexe Anforderungen mitbringen (z. B. Enterprise-SSO, Isolated-Schema, umfangreiches Berechtigungsmodell).
- Bauen Sie SaaS-Produkte auch als Weiterentwicklung eines bestehenden Systems?
- Ja. Häufig kommen Betriebe mit einem internen System, das zum SaaS werden soll. Der Umbau ist möglich, erfordert aber eine ehrliche Analyse, wo Multi-Tenancy nachträglich sauber realisierbar ist und wo neu gedacht werden muss.
Fynn-Luca Schulz (Head of Product & Strategy) und Julian Stosse (Head of Engineering) verantworten die Arbeit an Taskey und an den individuellen Systemen, die Schulz & Stosse entwickelt und betreibt.