Multi-Tenant-SaaS

In einem Multi-Tenant-Aufbau teilen sich die Kunden den Anwendungscode und die Infrastruktur, aber jeder sieht nur seine eigenen Daten, Nutzer und Einstellungen. So hält der Großteil moderner SaaS die Preise niedrig: eine Codebasis und ein Betriebsteam bedienen Hunderte von Kunden, statt einer separaten Installation für jeden.

Wann es sinnvoll ist

Multi-Tenancy ist die Standardwahl, wenn viele Kunden dasselbe Produkt mit unterschiedlichen Inhalten und Marken brauchen.

• Neue Funktionen und Korrekturen sollen alle Kunden gleichzeitig erreichen, aus einem einzigen Deployment
• Betriebskosten zählen: eine Infrastrukturrechnung, geteilt durch alle Kunden, schlägt einen eigenen Stack pro Kunde
• Kunden brauchen Konfiguration (Marke, Module, Inhalte), keine strukturell unterschiedliche Software

Wann nicht

Reine Multi-Tenancy wird unbequem, wenn Kunden harte Garantien brauchen. Wenn ein Kunde seine Daten mitnehmen können muss, strenge Compliance-Regeln erfüllen muss oder schlicht nicht in einer geteilten Datenbank sitzen will, reicht logische Isolation innerhalb einer Datenbank womöglich nicht aus. Auch Noisy-Neighbor-Probleme, bei denen die Last eines Kunden die Erfahrung aller anderen verschlechtert, wachsen mit der Skalierung.

Wie Cazullo es anwendet

Die Cazullo Platform verhält sich auf Code-Ebene wie Multi-Tenant-SaaS: eine Plattform, ein Team, viele Marken. Sie treibt die Isolation aber einen Schritt weiter als die übliche geteilte Datenbank. Jede Marke läuft in ihrem eigenen Firebase-Projekt auf Google Cloud, sodass ihre Daten, Nutzer und Zahlungskonfiguration in einer Infrastruktur leben, die nur dieser Marke gehört. Eine Marke bekommt die Ökonomie geteilter Software mit dem Eigentum eines dedizierten Stacks: ihre Daten gehören ihr, vollständig, vom ersten Tag an.