Multi-Mandanten-Architektur: Ein praxisorientierter Leitfaden für Architekten

Multi-Mandanten-Architektur ist ein Softwaredesign-Ansatz, bei dem eine einzelne Anwendungsinstanz mehrere Kunden bedient — sogenannte Mandanten — und gleichzeitig die Daten und das Verhalten jedes Mandanten von allen anderen isoliert hält. Das praktische Urteil bei der Modellauswahl: Betrachten Sie Mandantenfähigkeit als eine abgestufte Produktentscheidung. Beginnen Sie mit einem Pool-Modell für kostenempfindliche Kunden mit geringerem Risiko; verwenden Sie ein Hybrid- oder Bridge-Modell, wenn Ihre Kundenstruktur uneinheitlich ist; und stellen Sie dedizierte Silo-Infrastruktur für Unternehmenskunden oder regulierte Mandanten bereit, die eine vertraglich zugesicherte Isolation benötigen.

Die drei wichtigsten Zielkonflikte, mit denen sich jedes Team auseinandersetzt:

Isolation vs. Kosten: Eine stärkere Isolation bedeutet dedizierte Ressourcen und damit höhere Kosten pro Mandant.
Komplexität vs. Flexibilität: Gemeinsame Modelle sind kostengünstiger im Betrieb, erfordern jedoch eine strenge Durchsetzung auf Anwendungsebene, um Datenlecks zu verhindern.
Geschwindigkeit vs. Compliance: In Pool-Architekturen werden Mandanten innerhalb von Sekunden aufgenommen; Silo-Modelle können Minuten bis Stunden dauern, erfüllen dafür aber die Anforderungen von Prüfern und Beschaffungsteams von Unternehmen.

Inhaltsverzeichnis

Was bedeutet „Multi-Mandanten“ eigentlich?
Was sind die wichtigsten Mandantenmodelle?
Wie wählt man das richtige Mandantenmodell aus?
Implementierungs-Checkliste für Multi-Mandanten-Systeme
Sicherheit und Compliance in Multi-Mandanten-Umgebungen
Wie skaliert man eine Multi-Mandanten-Plattform, ohne die Leistung zu beeinträchtigen?
Wie verwaltet man den gesamten Lebenszyklus eines Mandanten?
Wie sehen Referenzarchitekturen in der Praxis aus?
Wie Ridiculous Engineering Multi-Mandanten-Architektur angeht
Wichtigste Erkenntnisse
Nützliche Quellen und weiterführende Literatur
Zusammenarbeit mit Ridiculous Engineering an Ihrer Multi-Mandanten-Plattform
Häufig gestellte Fragen

Was bedeutet „Multi-Mandanten“ eigentlich?

Ein Mandant ist eine eigenständige Organisation, ein Konto oder eine logische Kundeneinheit, die die Plattform gemeinsam nutzt. Ein einzelnes Unternehmen kann Tausende von Benutzern haben, die jedoch alle zu einem Mandanten gehören. Die Mandantengrenze ist die logische oder physische Linie, die die Daten, Konfiguration und das Verhalten eines Mandanten von denen eines anderen trennt.

Im Gegensatz dazu erhält bei einer Single-Mandanten-Architektur jeder Kunde eine dedizierte Anwendungsinstanz und Datenbank. Single-Mandanten-Bereitstellungen sind leichter zu verstehen, aber im großen Maßstab teuer im Betrieb. Multi-Mandanten-Fähigkeit ermöglicht es einer Anwendungsinstanz, viele Kunden zu bedienen. Deshalb setzen die meisten SaaS-Plattformen darauf, um von Dutzenden auf Tausende von Kunden zu skalieren, ohne das Kernsystem neu zu entwerfen.

Die geschäftlichen Ziele, die Teams zur Multi-Mandanten-Fähigkeit bewegen, sind einheitlich: geringere Infrastrukturkosten pro Kunde, eine zentrale Bereitstellungsfläche für Updates und Patches sowie ein reduzierter Betriebsaufwand. Die technischen Ziele sind ebenso einheitlich: Datenisolierung zwischen Mandanten, mandantenbewusstes Routing von Anfragen, mandantenspezifische Überwachung und die Möglichkeit, unterschiedliche Konfigurationen oder Funktionssätze pro Konto durchzusetzen.

Was sind die wichtigsten Mandantenmodelle?

AWS-Leitlinien stellen Isolation als Kontinuum von Silo bis Pool dar, mit Bridge-Modellen dazwischen. Dieses Modell ist die nützlichste gedankliche Grundlage für Architekturentscheidungen.

Three modular towers representing tenancy models

Silo (dedizierter Stack pro Mandant)

Jeder Mandant erhält seinen eigenen Anwendungsstack und seine eigene Datenbank. Die Isolation ist maximal: Ein Fehler, ein Sicherheitsverstoß oder eine übermäßige Arbeitslast bei einem Mandanten kann keinen anderen beeinträchtigen. Compliance-Prüfer schätzen dieses Modell, weil sich Datenresidenz und Zugriffskontrollen leicht nachweisen lassen. Die Kosten sind allerdings erheblich. Der Infrastrukturaufwand steigt linear mit der Anzahl der Mandanten, und die betriebliche Komplexität nimmt mit jeder neuen Bereitstellung zu. Die Wiederherstellung pro Mandant ist einfach, da jede Datenbank bereits auf einen Kunden beschränkt ist.

Schema pro Mandant (gemeinsame Datenbank, separate Schemas)

Alle Mandanten teilen sich eine Datenbank-Engine, aber jeder erhält sein eigenes Schema. Dieses Modell liegt zwischen Silo und vollständig gemeinsam genutzter Umgebung: Es bietet eine sinnvolle logische Trennung ohne die Kosten separater Datenbankinstanzen. Schema pro Mandant funktioniert gut, wenn die Anzahl der Mandanten eher im Hunderter- als im Tausenderbereich liegt, da eine übermäßige Anzahl von Schemas letztlich zu Problemen bei Migrationen und beim Verbindungspooling führt. Online-Schema-Migrationen erfordern eine sorgfältige Versionierung, um zu verhindern, dass mehrere Mandanten gleichzeitig gesperrt werden.

Gemeinsames Schema (Isolation auf Zeilenebene)

Eine Datenbank, ein Schema, die Zeilen aller Mandanten in denselben Tabellen. Dies ist das kostengünstigste Modell und erfordert die größte Disziplin. Row-Level-Security erfordert einen tenant_id-Filter bei jedem Lese- und Schreibvorgang. Eine einzige vergessene Abfrage, und es kommt zu einem Datenleck. Die Row-Level-Security-Richtlinien (RLS) von PostgreSQL oder Middleware auf Anwendungsebene können dies automatisch erzwingen, aber das Risiko eines fehlenden Filters ist real und die Folgen sind schwerwiegend.

Brücken- und Hybridmodelle

Ein Brückenmodell kombiniert gemeinsam genutzte Rechenressourcen mit unterschiedlichen Graden der Speicherisolation. Ein gängiges Muster ist eine gemeinsam genutzte Anwendungsebene, aber mandantenspezifische Datenbanken für die Speicherung. Das Deployment-Stamps-Muster von Azure geht noch weiter, indem dedizierte Infrastruktur für einen Mandanten oder eine Gruppe von Mandanten bereitgestellt und anschließend durch das Hinzufügen weiterer Stamps skaliert wird. Stamps können für einzelne Mandanten oder für mehrere Mandanten ausgelegt sein und Teams einen klaren Upgrade-Pfad bieten, wenn ein Mandant aus gemeinsam genutzten Ressourcen herauswächst.

Vergleich der Mandantenmodelle

Dimension	Silo	Schema pro Mandant	Gemeinsames Schema	Brücke/Hybrid
Isolationsgrad	Stark (physisch)	Mittel (logisch)	Schwach (durch die Anwendung erzwungen)	Konfigurierbar
Kosten pro Mandant	Hoch	Mittel	Niedrig	Mittel-hoch
Implementierungskomplexität	Hoch (betrieblicher Mehraufwand)	Mittel	Niedrig-mittel	Hoch
Skalierbarkeit	Lineares Kostenwachstum	Hunderte von Mandanten	Tausende von Mandanten	Flexibel
Eignung für Compliance	Ausgezeichnet	Gut	Erfordert Nachweise	Gut-Ausgezeichnet
Anpassungsfähigkeit	Vollständig	Hoch	Begrenzt	Hoch

The Best Cloud Native Embedded BI Tools: Find the Right Fit ...

Profi-Tipp: Behandle diese Tabelle nicht als endgültige Antwort. Die meisten Produktionsplattformen verwenden letztlich mindestens zwei Modelle gleichzeitig: Pooling für Standardtarife, Silo oder Stamp für Enterprise-Verträge. Entwirf deine Abstraktionen von Anfang an so, dass sie beide unterstützen.

Wie wählst du das richtige Mandantenmodell aus?

Die Entscheidung ist nicht rein technischer Natur. Mandantenfähigkeit als Produktmerkmal zu behandeln – etwas, das du bepreist und paketierst – unterscheidet Plattformen, die Enterprise-Umsätze erzielen, von denen, die darauf verzichten.

Arbeite diese Kriterien in der folgenden Reihenfolge durch:

Regulatorische und Compliance-Anforderungen. Wenn ein Mandant HIPAA-, PCI-DSS- oder SOC-2-Type-II-Prüfungen unterliegt, beginne für diese Konten mit Silo oder einem Schema pro Mandant. Die Isolation in einem gemeinsamen Schema lässt sich nur schwer überzeugend auditieren.
Vertragliche Anforderungen an den Datenstandort. Enterprise-Kunden verlangen zunehmend, dass Daten innerhalb bestimmter geografischer Grenzen bleiben. Silo- oder Stamp-Modelle machen dies unkompliziert; Modelle mit gemeinsamem Schema erfordern sorgfältige Kontrollen auf Datenbankebene.
Enterprise-SLA-Verpflichtungen. Wenn du eine Verfügbarkeit von 99,9 % oder mehr mit dedizierten Support-Zeitfenstern versprichst, stellt ein störender Nachbar in einem Pooling-Modell ein SLA-Risiko dar.
Preissensibilität deiner Kundenbasis. SMB- und Self-Service-Kunden zahlen selten genug, um dedizierte Infrastruktur zu rechtfertigen. Beginne für diese Segmente mit Pooling.
Reifegrad des Teams und Automatisierungsgrad. Silo-Modelle erfordern eine ausgereifte Infrastrukturautomatisierung. Wenn dein Team keinen neuen Mandanten-Stack innerhalb von fünf Minuten und ohne manuelle Schritte bereitstellen kann, wird dich der operative Aufwand belasten.
Variabilität der Workloads. Stark variable oder stoßartige Workloads profitieren von gepoolten Ressourcen, weil unkorrelierte Workloads das Verhältnis von Spitzenlast zu Durchschnittslast abflachen. Vorhersehbare Mandanten mit hohem Volumen eignen sich besser für dedizierte Ressourcen.

Der praktische Entscheidungsablauf: Beginne mit Pooling, wenn dein Kundenprofil unbekannt oder von SMB-Kunden dominiert ist. Wechsle zu einem hybriden Modell, sobald du deinen ersten Enterprise-Kunden mit Isolationsanforderungen gewinnst. Reserviere vollständige Silo-Isolation für regulierte Branchen oder Kunden mit vertraglichen Verpflichtungen zum Datenstandort.

Profi-Tipp: Vermeide die Alles-oder-nichts-Falle. Plattformen, die sich bei allen Kunden auf ein einziges Mandantenmodell festlegen, geben entweder zu viel für die Isolation von Kundenkonten mit geringem Wert aus oder verlieren Enterprise-Verträge, weil sie keine dedizierte Infrastruktur anbieten können. Integriere deine Mandantenstufe von Anfang an in dein Preismodell, auch wenn du heute nur eine Stufe hast.

Recommended Image

Teams, die aus Kostengründen vollständig mit Pooling beginnen, sehen sich später oft mit Problemen durch störende Nachbarn konfrontiert, deren Behebung teuer ist. Ein hybrider Start – Pooling für niedrigere Stufen, Isolation für Enterprise – vermeidet diese Kosten einer späteren Neuarchitektur. Die frühzeitige Abstimmung von Mandantenentscheidungen mit Geschäftszielen gehört zu den Entscheidungen mit der größten Hebelwirkung, die ein Architekturteam trifft.

Implementierungs-Checkliste für mandantenfähige Systeme

Das richtige Architekturmodell zu finden, ist die halbe Miete. Die andere Hälfte ist die technische Disziplin, es korrekt zu implementieren. Dies sind die wichtigsten Bausteine.

Mandantenidentität und Routing

Weise jedem Mandanten bei der Erstellung eine stabile, unveränderliche tenant_id zu und behandle sie in jeder Ebene des Stacks als erstklassiges Element.
Übertrage den Mandantenkontext durch den gesamten Anfragelebenszyklus: HTTP-Header, Middleware, Datenbankverbindungen und asynchrone Jobwarteschlangen müssen ihn alle mitführen.
Verwende Subdomain-Routing (tenant.app.com), pfadbasiertes Routing (/api/tenant/{id}/), oder JWT-Claims, um die Tenant-Identität am Edge aufzulösen, bevor die Anfrage die Anwendungslogik erreicht.

Datenpartitionierung und Verbindungspooling

Bei Modellen mit gemeinsamem Schema sollten Sie tenant_id-Filter automatisch auf der Datenzugriffsebene erzwingen, nicht am Aufrufort. Fest codierte Tenant-Logik am Aufrufort führt zu subtilen Sicherheitslücken und erhöhtem Wartungsaufwand.
Verwenden Sie PgBouncer oder einen ähnlichen Verbindungspooler, um Datenbankverbindungen effizient über große Tenant-Pools hinweg zu verwalten. Verbindungslimits pro Tenant verhindern, dass ein einzelner Tenant den gesamten Pool erschöpft.
Bei Modellen mit einem Schema pro Tenant sollten Sie die Erstellung und Löschung von Schemas als Teil des Bereitstellungs- und Offboarding-Lebenszyklus automatisieren.

Authentifizierung und Autorisierung

Unterstützen Sie Identity Provider pro Tenant: Unternehmenskunden möchten ihren eigenen SAML- oder OIDC-Provider verwenden.
Erzwingen Sie Tenant-bezogene Rollen und Berechtigungen, damit ein in Tenant A authentifizierter Benutzer nicht auf die Ressourcen von Tenant B zugreifen kann, selbst wenn ein gültiges Token vorliegt.
Verwenden Sie Tools wie Auth0, Okta oder AWS Cognito mit Tenant-bezogenen Claims, statt eine eigene Identitätsinfrastruktur von Grund auf zu entwickeln.

Bereitstellung und Migrationen

Automatisieren Sie die Tenant-Bereitstellung vollständig. Wenn die Bereitstellung manuelle Schemaänderungen oder menschliche Schritte erfordert, ist das System faktisch Multi-Instance und nicht mandantenfähig.
Versionieren Sie alle Schema-Migrationen und wenden Sie sie abwärtskompatibel an, damit Sie Änderungen für Tausende von Tenants ohne Ausfallzeit ausrollen können.
Führen Sie eine Tenant-Registry (einen Metadatenspeicher), die die Stufe, Konfiguration, den Bereitstellungsstatus und die zugewiesenen Ressourcen jedes Tenants erfasst.

Backups, Notfallwiederherstellung und Abrechnung nach Nutzung

Definieren Sie Wiederherstellungs-SLAs pro Tenant und testen Sie Wiederherstellungsverfahren für einzelne Tenants, nicht nur für vollständige Datenbankwiederherstellungen.
Erfassen Sie ab dem ersten Tag Nutzungsmetriken pro Tenant (API-Aufrufe, Speicher, Rechenleistung) und integrieren Sie diese in Ihr Abrechnungssystem. Plattformen wie Manaxo zeigen beispielhaft, wie SaaS-Produkte Nutzungsdaten den Abrechnungsstufen zuordnen.
Setzen Sie Kontingente und Ratenlimits pro Tenant durch, um gemeinsam genutzte Ressourcen zu schützen.

CI/CD- und Release-Strategie

Verwenden Sie Feature-Flags, um Änderungen vor der vollständigen Bereitstellung für eine Teilmenge von Tenants auszurollen. Dies ist der sicherste Weg, Tenant-spezifische Anpassungen zu testen, ohne die gesamte Flotte zu gefährden.
Automatisieren Sie CI/CD-Pipelines zur Bereitstellung Tenant-spezifischer Konfiguration zusammen mit dem Anwendungscode.
Zu vermeidende Anti-Patterns: fest codierte Tenant-Logik im Anwendungscode, manuelle Bereitstellungsschritte und unzureichende Beobachtbarkeit pro Tenant.

Profi-Tipp: Instrumentieren Sie Ihr System so, dass es ab dem ersten Entwicklungstag Tenant-gekennzeichnete Metriken und Logs ausgibt. Die nachträgliche Integration von Beobachtbarkeit in eine laufende mandantenfähige Plattform ist mühsam und teuer. Tenant-bewusstes Logging ist nicht optional — es ist die einzige Möglichkeit, Produktionsprobleme zu beheben, ohne bei der Untersuchung die Daten eines Tenants offenzulegen, während die Daten eines anderen untersucht werden.

Sicherheit und Compliance in mandantenfähigen Umgebungen

Sicherheit in mandantenfähigen Umgebungen ist keine einzelne Kontrolle. Sie besteht aus einer geschichteten Reihe von Entscheidungen, die sich über die gesamte Architektur hinweg summieren.

Verschlüsselung ruhender und übertragener Daten: Verschlüsseln Sie alle ruhenden Tenant-Daten mit AES-256 oder einem gleichwertigen Verfahren und erzwingen Sie TLS 1.2+ für alle übertragenen Daten. Erwägen Sie bei stark regulierten Tenants eine Verschlüsselung auf Feldebene für sensible Spalten, damit selbst Datenbankadministratoren keine Rohwerte lesen können.
Tenant-bezogenes IAM: Wenden Sie auf jeder Ebene Zugriffskontrollen nach dem Prinzip der geringsten Privilegien an. Cloud-IAM-Richtlinien, Datenbankrollen und Anwendungsberechtigungen sollten alle auf den Tenant beschränkt sein. Über normale Anwendungspfade darf kein tenantübergreifender Zugriff möglich sein.
Audit-Logging: Kennzeichnen Sie jeden Logeintrag mit tenant_id, speichern Sie Logs in einem manipulationssicheren System (AWS CloudTrail, Azure Monitor Logs) und bewahren Sie sie für den durch die geltenden Vorschriften vorgeschriebenen Zeitraum auf. SOC-2-Auditoren werden danach fragen.
Datenresidenz:Für Anforderungen an die Datenresidenz in den USA sollten Sie die Cloud-Region festlegen und bestätigen, dass verwaltete Dienste (Backups, Replikate, Analytics-Exporte) ebenfalls innerhalb der erforderlichen Region bleiben. Silo- und Stamp-Modelle erleichtern diesen Nachweis.
PCI DSS:Karteninhaberdaten müssen isoliert werden. Ein Shared-Schema-Modell ist ohne umfangreiche kompensierende Kontrollen kein gangbarer Weg zur PCI-Eingrenzung. Ein Silo- oder Schema-pro-Tenant-Modell ist die praktikable Wahl.
HIPAA:Geschützte Gesundheitsdaten erfordern eine Business Associate Agreement mit Ihrem Cloudanbieter sowie nachweisbare Zugriffskontrollen. Verschlüsselungsschlüssel und Auditprotokolle pro Tenant sind grundlegende Anforderungen.
Eindämmung von Sicherheitsverletzungen:Gestalten Sie Tenant-Grenzen so, dass ein kompromittierter Anwendungszugang nicht Tenant-Grenzen überschreiten kann. Verschlüsselungsschlüssel pro Tenant bedeuten, dass eine Schlüsselkompromittierung nur einen Tenant und nicht alle Tenants betrifft.
Incident Response:Führen Sie Runbooks pro Tenant, damit Ihr Bereitschaftsteam einen einzelnen Tenant isolieren, untersuchen und wiederherstellen kann, ohne andere zu beeinträchtigen. Planung der betrieblichen Resilienz sollte auch Tenant-spezifische Incident-Szenarien umfassen.

Dieser Artikel enthält allgemeine technische Hinweise und stellt keine Rechts- oder Compliance-Beratung dar. Klären Sie Ihre konkreten regulatorischen Verpflichtungen mit qualifizierter Rechtsberatung und Ihrem Compliance-Team.

Wie skalieren Sie eine mandantenfähige Plattform, ohne die Leistung zu beeinträchtigen?

Bei der Skalierung einer mandantenfähigen Plattform geht es weniger um die reine Kapazität als darum, Tenants voreinander zu schützen und gleichzeitig die Kosten vorhersehbar zu halten.

Nicht korrelierte Workloads gruppieren.Das Clustering von Tenants mit unterschiedlichen Nutzungsmustern glättet das Verhältnis von Spitzenlast zu Durchschnittslast über gemeinsam genutzte Ressourcen. Ein Tenant mit einer Spitze am Montagmorgen bildet mit einem Tenant mit einer Spitze am Freitagnachmittag einen besseren Pool als zwei Tenants mit identischen Spitzen am Montagmorgen. Dies ist eine der wirkungsvollsten Entscheidungen bei der Kapazitätsplanung, die Plattformteams treffen können.
Quoten und Ratenbegrenzung pro Tenant.Erzwingen Sie API-Ratenlimits, Zeitlimits für Abfragen und Speicherkontingente pro Tenant. Wenn ein Tenant ein Limit erreicht, drosseln oder stellen Sie seine Anfragen in eine Warteschlange, anstatt zuzulassen, dass sie den Pool beeinträchtigen. Dies ist die wichtigste Maßnahme gegen den Noisy-Neighbor-Effekt.
Topologie-Eskalation.Wenn die Workload eines Tenants dauerhaft das übersteigt, was durch Drosselung begrenzt werden kann, verschieben Sie ihn in eine dedizierte Ressourcenstufe. Dies ist kein Versagen der Architektur, sondern der bestimmungsgemäß funktionierende Upgrade-Pfad.
Autoscaling und Serverless.Serverless-Computing (AWS Lambda, Azure Functions) eignet sich gut für variable Workloads in gemeinsam genutzten Tiers, da Sie pro Aufruf statt pro bereitgestellter Instanz zahlen. Für Stamp-Bereitstellungen bewältigen Auto-Scaling-Gruppen mit vorgewärmter Kapazität vorhersehbares Wachstum. Siehe Muster zur Infrastrukturskalierungfür praktische Hinweise zur Vorbereitung auf hohen Datenverkehr.
Datenbankskalierung.Verbindungspooling ist bei großer Skalierung entscheidend. Bei Shared-Schema-Modellen kann eine einzelne PgBouncer-Instanz Tausende von Tenant-Verbindungen über eine kleine Anzahl tatsächlicher Datenbankverbindungen verwalten. Bei Schema-pro-Tenant-Modellen senken Aurora Serverless oder ähnliche verwaltete Datenbanken die Kosten für inaktive Schemas.
Metriken pro Tenant und Kostenzuordnung.Instrumentieren Sie die Plattform so, dass Compute-, Speicher- und Netzwerkkosten einzelnen Tenants zugeordnet werden können. Diese Daten unterstützen Preisentscheidungen und identifizieren Tenants, deren Nutzung ihre Infrastrukturkosten nicht deckt.

Wie verwalten Sie den gesamten Tenant-Lebenszyklus?

Mandantenfähigkeit ist ein Produktfeature und nicht nur eine technische Angelegenheit. Der Lebenszyklus vom Onboarding bis zum Offboarding muss ebenso sorgfältig geplant werden wie jede andere Produktfunktion.

Bereitstellung ohne manuellen Eingriff:Pooled Tenants sollten innerhalb von Sekunden vollständig über eine automatisierte Pipeline bereitgestellt werden: Tenant-Datensatz erstellen, tenant_id zuweisen, Standardkonfiguration anwenden, Willkommenszugangsdaten senden. Keine manuellen Schritte. Die Automatisierung des Onboardings unterscheidet eine Plattform von einer Sammlung manuell verwalteter Instanzen.
Bereitstellungsartefakte:Jedes Bereitstellungsereignis eines Tenants sollte einen vollständigen Satz von Artefakten erzeugen: Schema- oder Datenbankerstellung, Konfigurationsblobs, in einem Secrets-Manager gespeicherte Geheimnisse (AWS Secrets Manager, HashiCorp Vault), API-Schlüssel und einen Eintrag in der Tenant-Metadatenregistrierung.
Upgrades und Migrationen zwischen Tiers:Definieren Sie einen klaren Upgrade-Pfad für die Migration eines Mandanten von einem gemeinsam genutzten Modell über ein Schema pro Mandant und eine dedizierte Datenbank bis hin zu einer vollständig isolierten Umgebung. Jeder Schritt sollte automatisiert und getestet werden. Die Leitlinien zu Azure-Tenancy-Modellen beschreiben, wie erfolgreiche Plattformen gemeinsam genutzte Ebenen für Standardbenutzer und isolierte Stamps für Unternehmenskunden einsetzen. Dieses Muster erfordert einen getesteten Migrationspfad zwischen den Ebenen.
Verwaltung von Anpassungen:Verwenden Sie Feature-Flags (LaunchDarkly, Unleash oder einen eigenen Flag-Speicher), um die Verfügbarkeit von Funktionen mandantenspezifisch zu steuern. Speichern Sie die Mandantenkonfiguration in einem dedizierten Konfigurationsspeicher, nicht im Anwendungscode. Erweiterungspunkte sollten klar definiert und isoliert sein.
Abrechnung und Verbrauchsmessung:Erfassen Sie kontinuierlich Nutzungsmetriken und ordnen Sie sie Abrechnungsebenen zu. Für regulierte SaaS-Produkte zeigen Plattformen wie Intelligent Assessmentsbeispielsweise, wie gestaffelte Preise auf compliance-sensitive Kundensegmente abgestimmt werden. Erzwingen Sie feste Kontingente, bevor Abrechnungszeiträume enden, um unerwartete Mehrkosten zu vermeiden.
Deprovisionierung:Definieren Sie einen Prozess zur Löschung von Mandanten, der alle Mandantendaten entfernt oder archiviert, Zugangsdaten widerruft, Ressourcen freigibt und einen Prüfdatensatz zur Löschung erstellt. Sowohl die DSGVO als auch der CCPA verlangen einen nachweisbaren Datenlöschvorgang auf Anfrage.

Wie sehen Referenzarchitekturen in der Praxis aus?

AWS-Leitlinien für Mandantenfähigkeit

Die AWS Guidance for Multi-Tenant Architectures strukturiert den Gestaltungsraum entlang des Kontinuums von Silo über Bridge bis Pool. In einer gemeinsam genutzten AWS-Architektur teilen sich Mandanten ECS- oder Lambda-Compute-Ressourcen, einen einzelnen RDS- oder Aurora-Cluster sowie ein gemeinsames API Gateway mit mandantenbewussten Autorisierern. In einer Silo-Architektur erhält jeder Mandant seine eigene VPC, RDS-Instanz und IAM-Rollengrenze. Das Bridge-Modell nutzt typischerweise gemeinsame Compute-Ressourcen (ECS-Tasks oder Lambda), während der Speicher isoliert wird (mandantenspezifische RDS-Instanzen oder S3-Präfixe mit Bucket-Richtlinien).

AWS empfiehlt Amazon Cognito mit benutzerdefinierten Attributen für eine mandantenbewusste Identität, AWS IAM für die Isolation auf Ressourcenebene in Silo-Modellen sowie Amazon CloudWatch mit mandantenbezogenen Metriken zur Überwachung aller Modelle.

Azure-Deployment-Stamps

Microsoft’s Azure Architecture Center beschreibt das Muster der Deployment Stamps als Möglichkeit, mandantenfähige Plattformen durch die Bereitstellung eigenständiger Infrastruktureinheiten zu skalieren. Ein Stamp kann einen Unternehmenskunden bedienen (Single-Tenant-Stamp) oder eine Gruppe gemeinsam genutzter Mandanten (Multi-Tenant-Stamp). Kapazität wird durch das Hinzufügen von Stamps erweitert, nicht durch die Skalierung eines monolithischen gemeinsamen Clusters. Dieser Ansatz bietet Teams starke Isolationsgarantien und erhält gleichzeitig die Möglichkeit, kleinere Mandanten innerhalb eines Stamps gemeinsam zu nutzen.

Salesforce als kanonisches Beispiel

Salesforce ist das am häufigsten zitierte Beispiel für groß angelegte Mandantenfähigkeit in Enterprise-SaaS. Die Plattform bedient Hunderttausende Organisationen auf gemeinsam genutzter Infrastruktur und verwendet eine Kombination aus Isolation auf Anwendungsebene, mandantenspezifischen Metadaten und einer proprietären Abfrage-Engine, die Mandantengrenzen auf der Datenzugriffsebene durchsetzt. Die zentrale Erkenntnis aus der Salesforce’s-Architektur ist nicht die konkrete Technologie, sondern das Prinzip: Die Mandantenisolation muss auf der Datenebene durchgesetzt werden und darf nicht davon abhängen, dass einzelne Entwickler am Aufrufort daran denken.

SAP BTP und Enterprise-Plattformen

Die Referenzarchitektur von SAP’s für mandantenfähige SaaS-Lösungen auf BTP folgt ähnlichen Prinzipien: Mandantenisolation, automatisiertes Onboarding und Offboarding, gemeinsame Ressourcennutzung mit Governance-Kontrollen sowie mandantenbezogene Konfiguration für Enterprise-Erweiterungen. Enterprise-Plattformen konvergieren unabhängig vom zugrunde liegenden Technologie-Stack konsequent auf dieselben Muster.

Wie Ridiculous Engineering an mandantenfähige Architekturen herangeht

Ridiculous Engineering ist eine in Colorado ansässige Softwareentwicklungsberatung, die produktive mandantenfähige Plattformen für Kunden aus regulierten Branchen, SaaS-Start-ups und Enterprise-Softwareteams konzipiert und umgesetzt hat. Unser Prozess ist bewusst strukturiert und beginnt mit einer Analyse, bevor ein Modell ausgewählt wird.

Unser typisches Projekt folgt dieser Abfolge:

Analyse und Erfassung der Einschränkungen:Wir dokumentieren SLA-Ziele, Compliance-Anforderungen (HIPAA, PCI, SOC 2), die erwartete Mandantenskalierung nach 12 und 36 Monaten, Anpassungsanforderungen und den Automatisierungsreifegrad des Teams. Diese Eingaben bestimmen das anfängliche Mandantenmodell.
Entscheidung über das Mandantenmodell und Architekturdesign:Wir empfehlen ein Ausgangsmodell und definieren den Upgrade-Pfad. Für die meisten Kunden bedeutet das: zunächst ein gemeinsam genutztes Modell für den Start, mit einem festgelegten Migrationspfad zu einem Schema pro Mandant oder einem Silo für Unternehmenskonten.
Automatisierung und Bereitstellung:Wir erstellen Pipelines für die mandantenbezogene Bereitstellung ohne manuellen Eingriff, bevor wir Anwendungsfunktionen entwickeln. Die Bereitstellung ist ein zentrales Engineering-Ergebnis und kein nachträglicher Zusatz.
Schrittweise Implementierung:Wir implementieren Mandantenkontrollen auf der Datenzugriffsebene, nicht am Aufrufort, und validieren sie mit automatisierten Tests, die mandantenübergreifende Zugriffsversuche simulieren.
Runbook und Übergabe an den Betrieb:Wir liefern dokumentierte Runbooks für das Onboarding von Mandanten, Upgrades der Ebenen, die Reaktion auf Vorfälle und das Offboarding, damit Ihr Team die Plattform unabhängig betreiben kann.

Unsere Arbeit an der Consus CMS-Plattformveranschaulicht, wie ein Denken auf Plattformebene über Mandantenisolation und Cloud-Architekturin produktive Systeme umgesetzt wird, die ohne Neugestaltung skalieren. Wir bewerten bei jedem Projekt dieselben Einschränkungen: Compliance-Kontrollen, die erwartete Mandantenskalierung, die Tiefe der Anpassungen und die Fähigkeit des Teams, das von uns entwickelte System zu betreiben.

Wichtigste Erkenntnisse

Betrachten Sie Mandantenfähigkeit als gestaffelte Produktentscheidung: Starten Sie aus Kosteneffizienzgründen mit einem gemeinsam genutzten Modell, ergänzen Sie Isolationsebenen, sobald Compliance- und Enterprise-Anforderungen dies verlangen, und automatisieren Sie den gesamten Lebenszyklus der Mandanten vom ersten Tag an.

Punkt	Details
Mit einem Pool starten, Isolation einplanen	Beginnen Sie mit einem Shared-Schema- oder Pool-Modell für KMU-Kunden und definieren Sie den Upgrade-Pfad zu einem Silo-Modell, bevor Sie ihn benötigen.
tenant_id auf Datenebene erzwingen	Wenden Sie Tenant-Filter automatisch auf der Datenzugriffsebene an, nicht an einzelnen Aufrufstellen, um Datenlecks zu verhindern.
Provisionierung vollständig automatisieren	Manuelle Provisionierungsschritte bedeuten, dass Sie Multi-Instanz statt Multi-Tenancy haben; Onboarding auf Knopfdruck ist eine unverzichtbare Grundlage.
Mandantenbezogene Metriken frühzeitig erfassen	Kennzeichnen Sie Protokolle und Metriken vom ersten Tag an mit tenant_id; die nachträgliche Integration von Observability in eine laufende Plattform ist teuer und fehleranfällig.
Ridiculous Engineering entwickelt Designs dafür	Ridiculous Engineering entwickelt produktive Multi-Tenant-Plattformen mit automatisierter Provisionierung, abgestufter Isolation und einer Compliance-fähigen Architektur.

Nützliche Quellen und weiterführende Literatur

Architekten, die tiefer in Implementierungsdetails einsteigen möchten, finden mehrere maßgebliche Referenzen, die es sich zu speichern lohnt:

AWS-Leitfaden für Multi-Tenant-Architekturen: Die zentrale AWS-Referenz für das Silo-/Bridge-/Pool-Kontinuum mit Beispielarchitekturen, CDK-Konstrukten und Anleitungen für eine mandantenfähige Identität mit Amazon Cognito.
Azure Architecture Center: Multi-Tenant-Lösungen: Die umfassende Serie von Microsoft zu architektonischen Überlegungen, Deployment Stamps, dienstspezifischen Anleitungen und einer praxisnahen Implementierungs-Checkliste für auf Azure gehostete Multi-Tenant-Plattformen.
Azure-Mandantenmodelle: Konzentrierte Anleitung zur Auswahl zwischen Mandantenmodellen mit einer Analyse der Kompromisse und Empfehlungen für Upgrade-Pfade.
Shopify: Best Practices für Multi-Tenant-Architekturen: Ein praxisorientierter Überblick darüber, wie App-Entwickler von Dutzenden auf Tausende Händler skalieren, mit konkreten Implementierungsmustern.
SAP Architecture Center: Multi-Tenant-SaaS auf BTP: Eine auf Unternehmen ausgerichtete Referenzarchitektur zu Mandantenisolation, Onboarding, Ressourcenverwaltung und Konfigurationsmanagement für SAP-BTP-Erweiterungen.
Ridiculous Engineering-Ressourcen: Für Unterstützung bei der Implementierung, Fallstudien und Architekturprojekte siehe ridiculousengineering.com.

Zusammenarbeit mit Ridiculous Engineering an Ihrer Multi-Tenant-Plattform

Eine Multi-Tenant-Plattform von Anfang an korrekt zu entwickeln, kostet weniger, als eine fehlerhaft erstellte Plattform zu reparieren. Die teuerste Architekturentscheidung, die die meisten Teams treffen, ist die Festlegung auf ein einzelnes Mandantenmodell ohne Migrationspfad und die Erkenntnis zwei Jahre später, dass ihre Enterprise-Pipeline eine dedizierte Isolation erfordert, die sie nicht bereitstellen können.

Ridiculous Engineering’s Entwicklung kundenspezifischer Software Praxis basiert genau auf dieser Art von Architekturarbeit: zuerst die Analyse, an Einschränkungen orientiert und mit der Automatisierung und Dokumentation umgesetzt, die Ihr Team für den langfristigen Betrieb benötigt. Wir arbeiten mit SaaS-Start-ups, wachsenden Plattformen und etablierten Unternehmen in Colorado und darüber hinaus. Wenn Sie ein neues Multi-Tenant-System entwerfen oder ein bestehendes modernisieren, ist der richtige Zeitpunkt, die Architektur korrekt zu gestalten, bevor der erste Unternehmenskunde eine dedizierte Isolation verlangt. Kontaktieren Sie uns, um ein Gespräch über die Mandantenanforderungen Ihrer Plattform zu beginnen.

FAQ

Was ist ein Beispiel für eine Multi-Tenant-Anwendung?

Salesforce ist das am häufigsten genannte Beispiel: Hunderttausende Unternehmen nutzen gemeinsam dieselbe Anwendungsinfrastruktur, wobei die Mandantenisolation auf der Datenzugriffsebene durchgesetzt wird. Shopify verwendet dasselbe Muster für E-Commerce-Händler.

Was sind die wichtigsten Nachteile einer Multi-Tenant-Architektur?

Die wichtigsten Nachteile sind das Risiko von „lauten Nachbarn“ (die Arbeitslast eines Mandanten beeinträchtigt andere), die erhöhte Anwendungskomplexität durch mandantenbezogene Filterung und Weiterleitung sowie die Schwierigkeit, Prüfern im Compliance-Bereich die Isolation in Shared-Schema-Modellen nachzuweisen.

Was ist der Unterschied zwischen einer Single-Tenant- und einer Multi-Tenant-Architektur?

Bei einer Single-Tenant-Architektur erhält jeder Kunde eine dedizierte Anwendungsinstanz und Datenbank. Bei einer Multi-Tenant-Architektur bedient eine Anwendungsinstanz mehrere Kunden, wobei die Isolation je nach gewähltem Modell durch Anwendungslogik, Schema-Trennung oder physische Ressourcengrenzen durchgesetzt wird.

Was bedeutet mandantenfähige Architektur in Salesforce?

Salesforce verwendet ein Modell mit gemeinsam genutzter Infrastruktur, bei dem alle Kundenorganisationen auf derselben Anwendungsplattform ausgeführt werden. Die Mandantentrennung wird durch eine proprietäre, metadatengesteuerte Abfrage-Engine erzwungen, die jeden Datenvorgang automatisch auf die anfragende Organisation begrenzt und dadurch den Zugriff auf Daten anderer Mandanten über normale Anwendungspfade unmöglich macht.

Wann sollten Sie ein Silo-Modell anstelle eines Pool-Modells verwenden?

Verwenden Sie ein Silo-Modell, wenn für einen Mandanten regulatorische Anforderungen (HIPAA, PCI DSS), vertragliche Verpflichtungen zur Datenresidenz oder verbindliche Zusagen im Rahmen eines Enterprise-SLA gelten, die eine gemeinsam genutzte Infrastruktur nicht zuverlässig erfüllen kann. Für die meisten SMB- oder Self-Service-Kunden ist ein Pool-Modell standardmäßig die kostengünstige Wahl.

Multi-Mandanten-Architektur: Ein praxisorientierter Leitfaden für Architekten