Multi-Tenancy in SaaS

Multi-Tenancy existiert auf einem Spektrum. Gemeinsame Datenbank, gemeinsames Schema: Alle Daten der Mandanten befinden sich in denselben Tabellen, nur durch eine tenant_id-Spalte unterschieden. Geringste Kosten und einfachste Architektur, birgt aber das höchste Risiko von Datenlecks, wenn die tenant_id-Filterung in einer Abfrage übersehen wird. Gemeinsame Datenbank, separate Schemata: Jeder Mandant erhält sein eigenes Schema innerhalb der gemeinsamen Datenbank. Etwas bessere Isolation bei reduzierten Infrastrukturkosten im Vergleich zur vollständigen Trennung. Separate Datenbanken pro Mandant: Die Daten jedes Kunden befinden sich in einer vollständig isolierten Datenbank. Höchste Isolationsgarantie, einfachere Compliance, aber deutlich höhere Infrastrukturkosten und operative Komplexität (Datenbankmigrationen müssen über N Datenbanken hinweg ausgeführt werden). Die meisten SaaS-Unternehmen beginnen aus Kostengründen mit einem gemeinsamen Schema und migrieren zu einer stärkeren Isolation für Unternehmenssegmente, die Datenresidenz oder strengere Compliance-Kontrollen erfordern.

Multi-Tenancy schafft spezifische Herausforderungen bei der Fehlerbehebung für Support-Teams. Mandantenspezifische Fehler: Ein Problem, das nur Mandant A betrifft (aber nicht Mandant B, obwohl beide dieselbe Codeversion verwenden), wird typischerweise verursacht durch: den spezifischen Datenzustand oder die Konfiguration von Mandant A, ein nur für Mandant A aktiviertes Feature-Flag oder eine Ratenbegrenzung, die nur durch das Nutzungsmuster von Mandant A erreicht wird. Support-Mitarbeiter müssen die Untersuchung immer auf den spezifischen Mandanten eingrenzen: „Tritt dies bei diesem spezifischen Kunden auf, oder tritt es bei allen Kunden auf?“ Ein universell reproduzierbarer Fehler ist ein Produktfehler; ein mandantenspezifischer Fehler ist entweder ein Konfigurationsproblem oder ein Datenintegritätsproblem. Der Support muss vermeiden, die Daten eines Mandanten so zu korrigieren, dass die Daten eines anderen Mandanten beschädigt werden oder die Isolationsgarantien der Architektur verletzt werden könnten.

Multi-Tenancy birgt ein operatives Risiko des „lauten Nachbarn“: Der hohe Ressourcenverbrauch eines Mandanten kann die Leistung für andere Mandanten, die dieselbe Infrastruktur nutzen, beeinträchtigen. Product Ops ist gemeinsam mit dem Engineering für die Überwachungs- und Alarmierungsstrategie verantwortlich: Dashboards zum Ressourcenverbrauch pro Mandant identifizieren Mandanten, die sich den Ressourcengrenzen nähern, bevor sie andere beeinträchtigen. Ratenbegrenzungen und Ressourcenkontingente pro Mandant sind die primären Gegenmaßnahmen (Ratenbegrenzungen verhindern API-Übernutzung; Datenbankabfrage-Timeouts verhindern, dass langlaufende Abfragen gemeinsame Datenbankressourcen monopolisieren). Für Unternehmenskunden muss Product Ops verstehen, welche Isolationsgarantien die Architektur für Compliance-Zwecke bieten kann – die Vertriebs- und Support-Teams benötigen genaue Antworten auf Fragen wie „Sind meine Daten von anderen Kunden isoliert?“ in Beschaffungsgesprächen. Wenn die Architektur die erforderliche Isolation nicht bieten kann, kann die Enterprise-Stufe eine Single-Tenant- oder private Bereitstellungsoption erfordern.