Was bedeutet Multi-Tenancy?
Multi-Tenancy ist das Architekturprinzip, bei dem eine einzige Softwareinstanz mehrere Kunden (Tenants) bedient. Jeder Tenant sieht nur seine eigenen Daten und erlebt die Anwendung so, als wäre sie exklusiv für ihn.
Das Gegenteil — Single-Tenancy — bedeutet eine separate Instanz pro Kunde. Einfacher in der Isolation, aber teuer in Betrieb und Wartung.
Drei Isolationsmodelle
1. Shared Everything
Alle Tenants teilen sich Datenbank, Schema und Tabellen. Die Isolation erfolgt über eine tenant_id-Spalte in jeder Tabelle.
Vorteile:
- Niedrigste Infrastrukturkosten
- Einfaches Deployment und Updates
- Effiziente Ressourcennutzung
Risiken:
- Ein fehlender
WHERE tenant_id = ?Filter → Datenleck - Noisy Neighbor: Ein Tenant mit hoher Last beeinflusst alle anderen
- Komplexe Backup/Restore pro Tenant
Geeignet für: SaaS-Produkte mit vielen kleinen Tenants und moderaten Compliance-Anforderungen.
2. Shared Compute, Separate Database
Alle Tenants nutzen dieselbe Anwendung, aber jeder hat eine eigene Datenbank (oder ein eigenes Schema in PostgreSQL).
Vorteile:
- Stärkere Datenisolation
- Einfachere Tenant-spezifische Backups
- Performance-Isolation auf Datenbankebene
Risiken:
- Mehr Datenbankverbindungen (Connection Pool pro Tenant)
- Schema-Migrationen müssen für alle Datenbanken ausgeführt werden
- Höhere Infrastrukturkosten
Geeignet für: B2B-SaaS mit mittleren bis großen Tenants und regulatorischen Anforderungen.
3. Full Isolation (Silo)
Jeder Tenant erhält eine vollständig separate Infrastruktur — eigener Compute, eigene Datenbank, eigenes Netzwerk.
Vorteile:
- Maximale Isolation und Sicherheit
- Keine Noisy-Neighbor-Probleme
- Compliance-freundlich (Daten in eigener Region)
Risiken:
- Höchste Kosten
- Komplexes Deployment (N Umgebungen statt einer)
- Schwierigere Aggregation über Tenants hinweg
Geeignet für: Enterprise-Kunden mit strengen Compliance- oder Performance-Anforderungen.
Tenant-Kontext durchziehen
Der häufigste Fehler: Tenant-Isolation nur auf der API-Ebene implementieren. In der Praxis muss der Tenant-Kontext durch den gesamten Stack fließen:
- API Layer: Tenant aus JWT oder Header extrahieren
- Service Layer: Tenant-Kontext in jedem Service-Call weitergeben
- Database Layer: Row-Level Security (PostgreSQL) oder automatische
tenant_id-Filter - Cache Layer: Tenant-spezifische Cache-Keys
- Queue Layer: Tenant-ID in Message-Headern
- Logging/Monitoring: Tenant-ID in jedem Log-Eintrag
Skalierungsstrategien
Horizontales Sharding nach Tenant
Große Tenants bekommen eigene Shards, kleine Tenants werden auf Shared Shards zusammengefasst. Der Routing-Layer entscheidet basierend auf der Tenant-ID.
Tier-basierte Isolation
| Tier | Isolation | SLA | Preis |
|---|---|---|---|
| Starter | Shared Everything | 99,5 % | € |
| Professional | Shared Compute, Separate DB | 99,9 % | €€ |
| Enterprise | Full Silo | 99,95 % | €€€ |
Auto-Scaling pro Tenant
Anspruchsvoll aber machbar: Compute-Ressourcen werden pro Tenant basierend auf dessen Last skaliert. Kubernetes Namespaces oder separate Deployments ermöglichen dies.
Onboarding und Offboarding
Oft unterschätzt:
Onboarding — Was passiert, wenn ein neuer Tenant angelegt wird?
- Datenbank/Schema erstellen
- Initialdaten laden (Konfiguration, Standardwerte)
- DNS/Subdomain einrichten (falls Custom Domains)
- Billing-Integration aktivieren
Offboarding — Was passiert, wenn ein Tenant kündigt?
- Daten exportieren (DSGVO: Recht auf Datenportabilität)
- Daten nach Frist löschen (DSGVO: Recht auf Löschung)
- Ressourcen freigeben
- Audit-Trail archivieren
Fazit
Multi-Tenant-Architektur ist ein Spektrum, kein Entweder-Oder. Die meisten erfolgreichen SaaS-Produkte beginnen mit Shared Everything und bieten höhere Isolationsstufen als Premium-Feature an. Der Schlüssel liegt darin, den Tenant-Kontext von Anfang an sauber durch den gesamten Stack zu ziehen — nachträgliches Einbauen ist die teuerste Variante.