Architekturdiagramm für Multi-Tenant-SaaS: Silo-, Pool- und Bridge-Modell

Zeichne ein mandantenfähiges SaaS-Produkt so, wie die meisten Teams jedes System zeichnen, und es sieht genauso aus wie eines mit nur einem Mandanten: ein Gateway, ein paar Services, eine Datenbank. Die wichtigste Eigenschaft des Systems, nämlich wessen Daten wo landen können, taucht nirgends auf. Dabei bestimmt genau sie die schwierigsten Entscheidungen: wie Mandanten isoliert werden, wie große Kunden bedient werden, wie das Onboarding funktioniert und was ein lauter Nachbar (Noisy Neighbor) kaputt machen kann.

Dieser Guide zeigt, wie du Mandantenfähigkeit in einem Architekturdiagramm sichtbar machst: die Begriffe, was das Diagramm zeigen muss, das Silo-, Pool- und Bridge-Modell und ein Beispiel mit gemeinsam genutzten und dedizierten Ressourcen.

Die Begriffe

Die folgenden Begriffe sind in Texten über SaaS-Architektur verbreitet, auch in den SaaS-Leitfäden von AWS:

• Mandant (Tenant). Eine Kundenorganisation mit eigenen Nutzern und eigenen Daten.
• Steuerungsebene (Control Plane). Services, die Mandanten verwalten, statt das Produkt auszuliefern: Onboarding, Mandantenregister (Tenant Registry), Identität, Nutzungsmessung und Abrechnung.
• Anwendungsebene (Application Plane). Das Produkt selbst: die Services und Datenspeicher, die Mandanten jeden Tag nutzen.
• Mandantenkontext (Tenant Context). Die Mandanten-ID, die mit jedem Request mitreist, meist als Claim im Access Token.
• Silo. Ressourcen, die einem einzigen Mandanten vorbehalten sind, etwa eine separate Datenbank oder ein kompletter Stack.
• Pool. Ressourcen, die sich viele Mandanten teilen, getrennt durch Richtlinien und die Mandanten-ID.
• Bridge. Eine Mischung aus beidem: etwa gemeinsam genutztes Compute mit dedizierten Datenbanken für einige Mandanten.

Was das Diagramm zeigen muss

1. Woher der Mandantenkontext kommt. Der Identitätsanbieter und der Claim im Token, der die Mandanten-ID trägt.
2. Wo die Isolation durchgesetzt wird. Nicht „im Code“, sondern an einer bestimmten Stelle: eine Row-Level-Security-Richtlinie, ein Schema pro Mandant, eine separate Datenbank, eine IAM-Richtlinie.
3. Welche Ressourcen geteilt und welche dediziert sind. Kennzeichne jeden Datenspeicher und jeden Service als Pool oder Silo.
4. Wie ein Request seine Ressourcen findet. Das Routing oder der Lookup, der einen Mandanten zur richtigen Datenbank oder zum richtigen Stack schickt.
5. Wie Mandanten angelegt werden. Der Onboarding-Ablauf, der ins Register schreibt und dedizierte Ressourcen provisioniert.

Silo, Pool und Bridge

Modell	Was geteilt wird	Stärken	Kosten
Silo	Nichts in der Anwendungsebene	Starke Isolation, Tuning pro Mandant, einfachere Antworten auf Compliance-Fragen	Höhere Kosten pro Mandant, mehr Deployments im Betrieb
Pool	Compute und Daten, getrennt durch die Mandanten-ID	Niedrige Kosten pro Mandant, ein einziges Deployment	Isolation hängt an jeder Abfrage und jeder Richtlinie; laute Nachbarn
Bridge	Manche Schichten geteilt, manche dediziert	Isolation gezielt dort, wo sie zählt	Zwei Pfade, die gebaut, getestet und gezeichnet werden müssen

Viele Produkte starten mit einem Pool und verlagern ihre größten oder am stärksten regulierten Kunden später in Silos, womit das System zur Bridge wird. Das Diagramm sollte diese Aufteilung auf einen Blick zeigen.

Das Beispiel: Mandanten im Pool und ein Enterprise-Silo

Ein B2B-Analytics-Produkt hat Hunderte Standardmandanten und einen Enterprise-Kunden, Globex, der eine eigene Datenbank verlangt:

• Nutzer melden sich über einen mandantenfähigen Identitätsanbieter an. Ihr Access Token enthält tenant_id.
• Das API-Gateway validiert das Token und reicht den Mandantenkontext an die Analytics-API weiter.
• Die Analytics-API schlägt Tarifstufe (Tier) und Datenbank des Mandanten im Mandantenregister nach.
• Standardmandanten teilen sich eine PostgreSQL-Datenbank im Pool, in der Row-Level Security jede Abfrage nach tenant_id filtert.
• Globex bekommt eine dedizierte Datenbank, die der Onboarding-Service beim Anlegen des Mandanten provisioniert hat.

Zwei Rahmen trennen die Steuerungsebene von der Anwendungsebene, und die Labels an den Datenspeichern sagen, welches Isolationsmodell gilt. Jetzt kann ein Reviewer die richtigen Fragen stellen: Was passiert, wenn das Register ausfällt, und wer darf die Tarifstufe eines Mandanten ändern?

Regeln für Multi-Tenant-Diagramme

Tarifstufen zeichnen, nicht Mandanten

Zeichne nie eine Box pro Kunde. Zeichne einen Pfad pro Tarifstufe oder Deployment-Modell und nenne einen Beispielmandanten, wenn das hilft, so wie oben Globex.

Mandantenkontext an die Kanten schreiben

Schreib an jeden Hop, wie der Mandant identifiziert wird: JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Auch Hintergrundjobs und Event-Consumer brauchen den Mandantenkontext, und genau dort geht er am häufigsten verloren.

Den Durchsetzungspunkt ins Diagramm aufnehmen

„Isoliert per Mandanten-ID“ ist ein Versprechen; eine Row-Level-Security-Richtlinie, ein Schema pro Mandant oder ein separates Konto ist ein Mechanismus. Schreib den Mechanismus an den Datenspeicher oder setz einen Node vom Typ Richtlinie daneben.

Limits pro Mandant zeigen

Rate Limits, Kontingente und Parallelitätslimits pro Mandant sind das Mittel, mit dem ein Pool-System Mandanten voreinander schützt. Vermerke sie am Gateway und an den Services, die sie durchsetzen.

Nutzungsmessung und Abrechnung in der Steuerungsebene halten

Nutzungsereignisse pro Mandant speisen Nutzungsmessung und Abrechnung. Zeichne sie in der Steuerungsebene, damit sich die Anwendungsebene ganz auf das Bedienen von Requests konzentriert.

Häufige Fehler

• Keine Steuerungsebene. Onboarding, Mandantenregister und Identität sind Kernarchitektur, keine Admin-Tools.
• Isolation per Konvention. Eine Notiz wie „jede Abfrage filtert nach Mandant“ ist keine Kontrolle. Zeig die Richtlinie, die das durchsetzt.
• Unsichtbares Routing. Wenn manche Mandanten andere Ressourcen nutzen, zeichne den Lookup, der darüber entscheidet.
• Vergessene asynchrone Pfade. Queues, geplante Jobs und Analytics-Exporte, die die Mandanten-ID verlieren, sind eine klassische Quelle für Datenlecks.
• Ein einziges Riesendiagramm. Halte Datenresidenz (Regionen), Deployment und die logische Sicht in getrennten Diagrammen.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Pack Basis zwei Rahmen-Nodes hinzu: Control plane und Application plane.
3. Füge aus dem Pack Basis zwei Kasten-Nodes für die Standard- und die Globex-Nutzer hinzu, aus dem Pack Sicherheit einen Identitätsanbieter, aus dem Pack Cloud ein API-Gateway und aus dem Pack C4-Modell Container-Nodes für den Onboarding-Service und die Analytics-API.
4. Füge aus dem Pack Daten Postgres-Nodes für das Mandantenregister, die Pool-Datenbank und die dedizierte Datenbank hinzu, jeweils mit dem Isolationsmodell im Label.
5. Beschrifte die Kanten mit dem Mandantenkontext und stell die Provisionierungskante auf gestrichelt.

Das Beispiel nutzt 11 Diagramm-Nodes und passt damit in den Free-Plan. Für die Cloud- und Netzwerkschicht darunter sieh dir das AWS-VPC-Diagramm und die Seite zum Anwendungsfall Cloud an.

FAQ

Welches Isolationsmodell soll ich wählen? Geh von den Anforderungen deiner Kunden und deinen Kosten pro Mandant aus. Pool ist im Betrieb am günstigsten, Silo lässt sich einem Security-Reviewer am leichtesten erklären, und mit Bridge kannst du beides anbieten. Schreib die Begründung ins Diagramm.

Wie zeige ich Hunderte Mandanten? Gar nicht. Zeig jede Tarifstufe oder jedes Deployment-Modell einmal und lass die Liste der Mandanten im Register, wo sie hingehört.

Braucht jeder Mandant ein eigenes Diagramm? Nein. Ein Diagramm pro Architektur, mit den Tarifstufen darauf. Ein Enterprise-Mandant im Silo kann ein eigenes Deployment-Diagramm bekommen, wenn er in einem separaten Konto oder einer eigenen Region läuft.

Wie zeige ich Datenresidenz? Mit Regionsrahmen in einem separaten Deployment-Diagramm, die jeweils die Stacks oder Datenbanken der Mandanten enthalten, die dort bleiben müssen.

Wohin gehören Verschlüsselungsschlüssel pro Mandant? Neben die Datenspeicher, die sie schützen, als Node aus dem Pack Sicherheit oder als Notiz, zusammen mit dem Schlüsselverwaltungsdienst, der sie verwahrt.

Kostenlos starten — ein Seat, keine Kreditkarte.