Multi-Tenancy
Was ist Multi-Tenancy?
Multi-Tenancy -- auf Deutsch Mandantenfähigkeit -- bezeichnet eine Softwarearchitektur, in der eine einzelne Instanz einer Anwendung mehrere Kunden (Tenants) gleichzeitig bedient. Jeder Tenant hat seine eigenen Daten, Konfigurationen und oft auch ein eigenes Branding, teilt sich aber die zugrundeliegende Infrastruktur und Codebasis mit allen anderen Tenants.
Der Gegenentwurf ist Single-Tenancy, bei der für jeden Kunden eine separate Instanz der Software betrieben wird. Multi-Tenancy ist das vorherrschende Architekturmodell im SaaS-Bereich -- von Salesforce über Slack bis hin zu Shopify nutzen praktisch alle großen SaaS-Plattformen diesen Ansatz.
Warum ist das wichtig?
Für SaaS-Unternehmen ist Multi-Tenancy der Schlüssel zur wirtschaftlichen Skalierung. Wenn jeder Kunde eine eigene Instanz bekommt, steigen die Infrastrukturkosten linear mit der Kundenzahl. Bei 1.000 Kunden betreibt man 1.000 Server, pflegt 1.000 Datenbanken und rollt Updates 1.000 Mal aus. Das ist weder wirtschaftlich noch operativ tragbar.
Multi-Tenancy bricht diese Linearität auf. Hunderte oder tausende Kunden teilen sich dieselbe Infrastruktur, wodurch die Kosten pro Kunde drastisch sinken. Updates werden einmal deployed und sind sofort für alle Tenants verfügbar. Monitoring, Backup und Wartung erfolgen zentral. Dieses Effizienzmodell ermöglicht es SaaS-Unternehmen, auch kleine Kunden profitabel zu bedienen -- die Grundlage für Self-Service-Modelle und niedrige Einstiegspreise.
Die Herausforderung liegt in der Datenisolation. Kein Tenant darf jemals Daten eines anderen Tenants sehen oder verändern können. Ein einziger Data Leak zwischen Tenants kann das Vertrauen aller Kunden zerstören und regulatorische Konsequenzen haben -- besonders in sensiblen Branchen wie FinTech oder HealthTech. Die Isolation muss daher auf mehreren Ebenen abgesichert werden: Datenbankebene, Anwendungsebene, API-Ebene und Infrastrukturebene.
Multi-Tenancy in der Praxis
Es gibt drei grundlegende Strategien für die Datenisolation:
Shared Database, Shared Schema: Alle Tenants teilen sich dieselbe Datenbank und dieselben Tabellen. Die Zuordnung erfolgt über eine tenant_id-Spalte in jeder Tabelle. Diese Variante ist am effizientesten, erfordert aber besondere Sorgfalt, damit jede Abfrage den Tenant-Filter enthält. Ein vergessener Filter kann sofort zu einem Data Leak führen. Row-Level Security auf Datenbankebene (etwa in PostgreSQL) bietet hier eine zusätzliche Absicherung.
Shared Database, Separate Schemas: Jeder Tenant bekommt ein eigenes Datenbankschema innerhalb derselben Datenbankinstanz. Die Isolation ist stärker als bei Shared Schema, und Migrationen können pro Tenant durchgeführt werden. Der Overhead ist moderat.
Separate Databases: Jeder Tenant hat eine eigene Datenbank. Die stärkste Isolation, aber auch der höchste Verwaltungsaufwand. Diese Variante wird typischerweise für Enterprise-Kunden oder regulierte Branchen eingesetzt, die eine physische Datentrennung fordern.
Beispiel: Ein SaaS-Startup baut eine Projektmanagement-Plattform mit Node.js. Für die ersten 500 Kunden nutzt das Team Shared Database mit Row-Level Security in PostgreSQL. Jeder API-Request extrahiert die Tenant-ID aus dem JWT-Token und setzt sie als Session-Variable -- die Datenbank filtert automatisch alle Abfragen. Für Enterprise-Kunden mit Compliance-Anforderungen bietet das Team optional Separate Databases an, die über eine Tenant-Router-Schicht angesteuert werden. Die gesamte Tenant-Logik ist in einem Middleware-Layer gekapselt, sodass die Geschäftslogik tenant-agnostisch bleibt.
In Microservices-Architekturen muss die Tenant-Information über Service-Grenzen hinweg propagiert werden -- typischerweise über HTTP-Header oder Message-Metadaten. Eine zentrale Tenant-Resolution-Middleware stellt sicher, dass kein Service versehentlich ohne Tenant-Kontext operiert.
Verwandte Konzepte
- Microservices -- Tenant-Isolation über Service-Grenzen hinweg
- DSGVO in der Softwareentwicklung -- Datenschutzanforderungen für Multi-Tenant-Systeme
- Node.js-Backend -- Backend-Framework für mandantenfähige Anwendungen
- Cloud & DevOps -- Infrastruktur für skalierbare Multi-Tenant-Deployments
- SaaS und digitale Plattformen -- Branchenlösungen für Multi-Tenant-Architekturen