Aufbau von Multi-Tenant-SaaS: Arbeitsbereiche, Rollen, Abrechnung und Isolation

Multi-Tenant-SaaS ist die Standardarchitektur für jede B2B-Plattform, die über eine Handvoll Kunden hinauswachsen möchte. Doch der Teufel steckt im Detail: Wie Sie Workspaces modellieren, Rollen zuweisen, Abrechnungen strukturieren und Mandanten isolieren, entscheidet darüber, ob Ihre Plattform reibungslos skaliert oder unter der Komplexität zusammenbricht. Bei DigiForge haben wir diese Systeme in Dutzenden von SaaS-Produkten aufgebaut und wieder neu aufgesetzt. Hier ist, was wir gelernt haben.

Workspaces: Die grundlegende Organisationseinheit

Ein Workspace ist ein logischer Container, der Benutzer, Daten und Konfiguration für einen einzelnen Kunden (oder ein Team innerhalb eines Kunden) gruppiert. Wir haben erlebt, dass Teams Workspaces mit Abrechnungskonten oder sogar mit Projekten gleichsetzen – tun Sie das nicht. Behalten Sie den Workspace als grundlegenden Mandantenbereich bei und legen Sie andere Konzepte darüber.

Wichtige Designentscheidungen:

• Hierarchisch oder flach? Manche Plattformen benötigen Workspaces innerhalb von Workspaces (z. B. ein Unternehmen mit mehreren Abteilungen). Wir empfehlen eine zweistufige Hierarchie: Organisation (Abrechnungseinheit) und Workspace (Teameinheit). Vermeiden Sie tiefere Verschachtelungen, es sei denn, es ist unbedingt erforderlich – sie verkomplizieren die Rollenvererbung und den Datenzugriff.
• Eindeutige Identifikatoren: Verwenden Sie einen menschenlesbaren Slug (wie acme oder acme-marketing) für den Workspace in URLs, aber verlassen Sie sich intern immer auf eine UUID. Slugs können sich ändern; UUIDs sollten es nicht.
• Soft-Delete mit Gnadenfrist: Das Löschen eines Workspace ist eine drastische Maßnahme. Implementieren Sie ein 30-tägiges Soft-Delete, damit Benutzer Daten wiederherstellen können. Stellen Sie die Abrechnung sofort ein, behalten Sie die Daten jedoch bis zum Ablauf der Gnadenfrist.

Wenn sich ein neuer Benutzer anmeldet, sollte der Onboarding-Ablauf bedacht werden. Soll er zuerst einen Arbeitsbereich erstellen oder eine Sandbox erkunden können? Wir bevorzugen einen geführten Ablauf, bei dem der Benutzer eine Organisation, dann seinen ersten Arbeitsbereich erstellt und sofort aufgefordert wird, Teammitglieder einzuladen. Dies reduziert Reibungsverluste und vermittelt die Erwartung, dass die Plattform kollaborativ ist.

Ein häufiger Fehler ist es, Abrechnungspläne direkt an Arbeitsbereiche zu koppeln. Stattdessen sollte die Abrechnung an eine Organisation gebunden werden, die einen oder mehrere Arbeitsbereiche enthält. Dies ermöglicht Unternehmen eine einzige Rechnung, während jedes Team seinen eigenen Arbeitsbereich erhält.

Rollen und Berechtigungen: Fein granular, aber nicht zu fein

Rollenbasierte Zugriffskontrolle (RBAC) ist der Industriestandard, aber die Granularität ist entscheidend. Bei DigiForge beginnen wir normalerweise mit drei integrierten Rollen – Admin, Mitglied, Betrachter – und erlauben benutzerdefinierte Rollen für erweiterte Pläne. Die Admin-Rolle hat die volle Kontrolle über den Arbeitsbereich, Mitglieder können die meisten Ressourcen erstellen und bearbeiten, und Betrachter haben nur Lesezugriff.

Wo es knifflig wird, ist der Berechtigungsumfang. Berechtigungen sollten standardmäßig auf den Arbeitsbereich beschränkt sein, aber möglicherweise werden organisationsweite Berechtigungen (z. B. Abrechnung verwalten) oder sogar bereichsübergreifender Lesezugriff für konsolidierte Berichte benötigt. Modellieren Sie Berechtigungen als eine Reihe von Aktion:Ressource-Paaren und weisen Sie sie Rollen zu. Speichern Sie die Zuordnungen in einer Verknüpfungstabelle: (workspace_id, user_id, role_id).

Ein Muster, das sich bei uns bewährt hat, ist das Caching der Benutzerrolle in einem Sitzungstoken (JWT), anstatt bei jeder Anfrage die Datenbank abzufragen. Aber Vorsicht: Wenn Sie Rollen in JWTs cachen, benötigen Sie einen Mechanismus, um Token bei einer Rollenänderung zu invalidieren (z. B. kurze Token-Laufzeit oder eine Blocklist).

Denken Sie auch an die Rollenvererbung: Sollte ein Organisations-Admin automatisch Admin in allen Workspaces sein? Unsere Faustregel: Organisationsrollen geben eine Obergrenze vor, aber Workspace-Rollen können restriktiver sein. Beispielsweise kann ein Org-Admin auf jeden Workspace zugreifen, aber ein Workspace-Admin nicht auf die Abrechnung.

Abrechnung und Preismodelle: Metadaten, nicht Geschäftslogik

Bei der Abrechnung wird Multi-Tenancy richtig ernst. Ihr Preismodell – pro Sitzplatz, pro Workspace, nutzungsbasiert oder gestaffelt – muss sich in Ihrem Datenmodell widerspiegeln, aber Ihr Abrechnungssystem sollte von Ihrer Kernanwendung entkoppelt sein. Verwenden Sie einen Drittanbieter für die Abrechnung (Stripe, Recurly, Chargebee) und speichern Sie nur die Abonnement-ID und die Plan-ID in Ihrer Datenbank.

Wir empfehlen den folgenden Datenbankansatz:

1. Eine plans-Tabelle, die den Plan-Slug, den Preis und Feature-Flags definiert (z. B. max_users, storage_gb, api_rate_limit).
2. Eine organizations-Tabelle mit einer current_plan_id und billing_provider_subscription_id. Verknüpfen Sie Organisationen über eine Join-Tabelle mit Arbeitsbereichen.
3. Eine features-Tabelle (oder eine einfache JSON-Spalte), die Überschreibungen speichert. Wenn ein Kunde beispielsweise einen individuellen Tarif aushandelt, überschreiben Sie den Planpreis auf Organisationsebene.

Der schwierigste Teil ist die Zugriffsbeschränkung basierend auf dem Plan. Sie haben zwei Möglichkeiten: Grenzen in der Anwendung erzwingen (prüfen Sie max_users vor dem Einladen) oder über Datenbankzeilenanzahlen und Trigger. Wir bevorzugen die Erzwingung auf Anwendungsebene, da sie benutzerfreundlichere Fehlermeldungen ermöglicht, fügen aber immer einen nächtlichen Abgleichsjob hinzu, der Organisationen markiert, die ihre Grenzen überschreiten.

Plan-Upgrades und -Downgrades erfordern sorgfältige Handhabung. Wenn ein Kunde ein Upgrade durchführt, gewähren Sie sofort Zugriff auf neue Funktionen, rechnen aber die Abrechnung über Ihren Anbieter anteilig ab. Bei einem Downgrade müssen Sie entscheiden: Zugriff auf Funktionen blockieren, die den neuen Plan überschreiten, oder eine Gnadenfrist gewähren? Wir empfehlen eine Gnadenfrist bis zum Ende des aktuellen Abrechnungszeitraums, nach der Sie die Einschränkungen durchsetzen.

Eine Lektion aus der Praxis: Lassen Sie niemals zu, dass Abrechnungsfehler zu Datenverlust führen. Wenn eine Zahlung fehlschlägt, führen Sie eine abgestufte Degradierung durch (z. B. Schreiboperationen einschränken), aber löschen Sie keine Daten. Ihr Kunde wird irgendwann zahlen.

Mandantenisolierung: Shared vs. Silo

Die Isolierung ist die folgenreichste Architekturentscheidung. Der klassische Trade-off besteht zwischen einer gemeinsamen Datenbank (eine Datenbank für alle Mandanten, mit einer tenant_id-Spalte in jeder Tabelle) und einer Datenbank pro Mandant (jeder Arbeitsbereich erhält eine eigene Datenbank). Wir haben beides betrieben und uns für die meisten Projekte auf einen hybriden Ansatz festgelegt.

• Gemeinsam mit striktem RLS: Gut für kleine bis mittlere Mandanten (unter 10.000 Benutzern). Row-Level Security ist in Postgres integriert, und wir verwenden eine Session-Variable (app.tenant_id), um jede Abfrage zu filtern. Dies ist am einfachsten zu betreiben und zu aktualisieren.
• Datenbank pro Mandant: Notwendig, wenn Mandanten strenge Compliance-Anforderungen haben (HIPAA, SOC 2, GDPR-Datenresidenz) oder wenn die Anwendung pro Mandant I/O-intensiv ist. Der operative Aufwand ist real – Schema-Migrationen müssen auf hunderte Datenbanken angewendet werden – aber Tools wie Flyway und automatisierte CI machen es handhabbar.
• Schema pro Mandant: Ein Mittelweg mit separaten Schemas innerhalb einer Datenbank. Bietet mehr Isolierung als eine gemeinsame Tabelle, aber weniger operativen Aufwand als vollständige Datenbanken. Wir verwenden dies für unsere günstigeren Tarife und upgraden Kunden auf Datenbank pro Mandant, wenn nötig.

Unabhängig von der Isolierungsstrategie: Erlauben Sie niemals direkten Datenbankzugriff vom Client aus. Leiten Sie immer über eine API-Schicht, die die Mandantenidentität durchsetzt. Und um Himmels willen: Verwenden Sie niemals tenant_id in URLs, ohne zu validieren, dass der authentifizierte Benutzer zu diesem Mandanten gehört.

Datenmigration zwischen Isolierungsstufen ist Realität. Wenn ein Mandant beispielsweise die gemeinsame Datenbank entwachsen ist, müssen Sie ihn möglicherweise auf eine dedizierte Datenbank migrieren. Planen Sie frühzeitig dafür: Schreiben Sie ein Migrationsskript, das Daten exportiert und importiert, und testen Sie es mit produktionsnahen Daten. Es sollte möglich sein, ohne Ausfallzeiten zu laufen, indem ein Blue-Green-Ansatz verwendet wird.

Automatisiertes Provisioning: Die Maschine macht's

Neue Mandanten manuell aufzusetzen mag für die ersten zehn Kunden funktionieren, aber es skaliert nicht. Wie ContractorHUBs jüngste Patentanmeldung zeigt, ist die Null-Touch-Implementierung ein entscheidendes Unterscheidungsmerkmal für Multi-Tenant-SaaS [1]. Wir haben Provisioning-Workflows entwickelt, die alles automatisieren – von der Datenbankerstellung (oder Schema-Klonen) über das Befüllen mit Standarddaten bis hin zum Versand von Willkommens-E-Mails.

Ein typischer automatisierter Provisioning-Pipeline:

1. Der Benutzer registriert sich, erstellt eine Organisation und wählt einen Plan aus.
2. Ein Webhook von Ihrem Abrechnungsanbieter löst einen Provisioning-Job aus (z. B. eine serverlose Funktion oder einen Kubernetes-Job).
3. Der Job erstellt die Isolationsschicht des Mandanten (Schema oder Datenbank), führt die initialen Migrationen durch und befüllt Standardrollen und -einstellungen.
4. Ein zweiter Job sendet eine E-Mail mit Anmeldeanweisungen und nächsten Schritten.
5. Der Benutzer wird zum neuen Arbeitsbereich weitergeleitet – voll funktionsfähig innerhalb von Sekunden.

Idempotenz ist hier unverhandelbar. Wenn der Provisioning-Job mittendrin fehlschlägt, muss ein erneuter Versuch sicher sein. Wir kapseln den gesamten Prozess in einer Zustandsmaschine mit einer provisioning_status-Spalte in der Organisationstabelle: pending → creating → active → failed. Fehlgeschlagene Zustände werden zur manuellen Bearbeitung in eine Dead-Letter-Queue verschoben.

Vergessen Sie nicht, die unterstützende Infrastruktur bereitzustellen: DNS-Einträge für benutzerdefinierte Domains, CDN-Cache-Warmer, API-Ratenbegrenzungen pro Mandant und Überwachungsalarme. Automatisieren Sie alles, was skriptbar ist, denn manuelle Schritte werden unter Druck vergessen.

Fazit: Die Multi-Tenant-Denkweise

Multi-Tenancy ist nichts, was man nach dem Start nachrüstet. Es muss von Anfang an Ihr Datenmodell, Ihre Zugriffskontrolle, Ihre Abrechnungsintegration und Ihre Bereitstellungsstrategie leiten. Die gute Nachricht: Wenn Sie diese vier Säulen – Arbeitsbereiche, Rollen, Abrechnung, Isolation – richtig umsetzen, wird der Rest Ihrer SaaS deutlich einfacher zu entwickeln und zu warten.

Jede SaaS ist anders, aber die obigen Muster haben sich in verschiedenen Branchen bewährt. Egal, ob Sie gerade mit Ihrem MVP beginnen oder auf Tausende von Mandanten skalieren – wir ermutigen Sie, diese Entscheidungen gründlich zu durchdenken. Und wenn Sie eine zweite Meinung zu Ihrer Architektur wünschen, wir freuen uns immer über eine Überprüfung.