Multi-Tenant-Architektur: ein SaaS für viele Kunden

Wenn ein SaaS-Produkt wächst, taucht früher oder später eine strukturelle Entscheidung auf: Richten wir für jeden Kunden eine separate Installation ein oder teilen sich alle dieselbe Plattform? Die Multi-Tenant-Architektur beantwortet diese Frage, indem ein einziges System viele Kunden —die Tenants— bedient, während jeder seinen Bereich als eigenen und isolierten wahrnimmt. Es ist das Modell hinter den meisten modernen Abo-Softwarelösungen, und es gut zu verstehen vermeidet sowohl die Mehrkosten doppelter Infrastruktur als auch das Risiko, fremde Daten zu vermischen.

Was Multi-Tenant bedeutet

Ein Tenant ist jeder Kunde oder jede Organisation, die das Produkt nutzt. In einer Multi-Tenant-Architektur teilt sich diese Gruppe von Kunden dieselbe Anwendung und meist dieselbe Datenbank, während eine Isolationsschicht sicherstellt, dass niemand Informationen sieht, die ihm nicht gehören. Gegenüber dem Single-Tenant-Modell —eine dedizierte Instanz pro Kunde— reduziert der geteilte Ansatz die zu betreibende und zu aktualisierende Oberfläche drastisch.

Isolation lässt sich auf verschiedene Weisen erreichen, und es lohnt sich, sie zu kennen, da sie alle weiteren Entscheidungen prägen:

• Geteilte Datenbank mit Tenant-Spalte: jede Tabelle enthält eine Kundenkennung und jede Abfrage filtert danach. Die kosteneffizienteste Option und die anspruchsvollste in puncto Disziplin.
• Schema pro Tenant: dieselbe Datenbank, aber jeder Kunde hat sein eigenes Schema. Mehr Isolation, etwas mehr Verwaltung.
• Datenbank pro Tenant: starke Trennung, nützlich für Kunden mit strengen regulatorischen Anforderungen, zum Preis von mehr zu wartender Infrastruktur.

Kosten- und Wartungsvorteile

Der Grund, warum dieses Modell dominiert, ist einfach: Man betreibt ein einziges System statt Hunderter. Das hat unmittelbare Folgen.

• Ein Deployment, alle aktualisiert: eine Korrektur oder eine neue Funktion erreicht alle Kunden gleichzeitig, ohne kundenweise Update-Kampagnen.
• Bessere Ressourcennutzung: die Kapazität wird geteilt, sodass die Spitzen der einen durch die Ruhe der anderen ausgeglichen werden, statt separat zu überdimensionieren.
• Schnelles Onboarding: einen neuen Kunden anzulegen heißt, einen Datensatz zu erstellen, nicht eine vollständige Installation bereitzustellen.
• Einheitliche Observability: Metriken, Logs und Alarme leben an einem Ort, was das Erkennen von Problemen erleichtert, bevor sie eskalieren.

Diese Ersparnis ist nicht umsonst: Sie wird mit sorgfältigerer Technik bezahlt. Der Aufwand verlagert sich von der Hardware auf das Design.

Die eigentliche Herausforderung: Isolation und Sicherheit

Eine Plattform zu teilen bedeutet, dass ein Isolationsfehler nicht einen Kunden, sondern potenziell alle betrifft. Deshalb ist Sicherheit keine Schicht mehr, sondern ein übergreifendes Prinzip.

Im Multi-Tenant ist Isolation keine Funktion, die man einmal testet: Sie ist eine Eigenschaft, die man in jeder Abfrage, jedem Endpunkt und jedem Hintergrundjob verteidigt.

Die Punkte, an denen Sorgfalt am wichtigsten ist:

• Tenant-Filterung an der Quelle: die Kundenkennung muss in der Datenzugriffsschicht durchgesetzt werden, nicht dem Gedächtnis jeder Abfrage überlassen. Ein einziges vergessenes WHERE ist ein Leck.
• Konsistente Autorisierung: zu authentifizieren, wer man ist, reicht nicht; jede Anfrage muss prüfen, dass der Nutzer zu dem Tenant gehört, dessen Daten er anfordert.
• Isolation in allem Asynchronen: Queues, geplante Aufgaben, Caches und Exporte müssen ebenfalls die Tenant-Grenze respektieren, nicht nur Web-Anfragen.
• Laute Nachbarn: ein sehr aktiver Kunde sollte den Service der übrigen nicht beeinträchtigen; es braucht Limits und Kontingente.

Tests, die böse Absicht unterstellen

Der zuverlässigste Weg, Isolation aufrechtzuerhalten, ist, sie als etwas zu behandeln, das automatisch und systematisch überprüft wird: Tests, die absichtlich versuchen, auf Daten eines anderen Tenants zuzugreifen, und die immer fehlschlagen müssen. Ist diese Prüfung nicht automatisiert, hängt die Isolation vom Gedächtnis der programmierenden Person ab, und das skaliert nicht.

Wann es sinnvoll ist (und wann nicht)

Multi-Tenant glänzt, wenn man dasselbe Produkt vielen Kunden mit ähnlichen Bedürfnissen anbietet und schnell auf einer gemeinsamen Basis iterieren will. Es ist das natürliche Terrain eines Content-CMS oder eines SaaS-Ecommerce, wo der Wert darin liegt, eine von allen geteilte Plattform zu verbessern.

Es gibt jedoch Fälle, in denen stärkere oder sogar dedizierte Isolation angebracht ist: regulatorische Anforderungen, die eine physische Datentrennung verlangen, Kunden mit so tiefgreifenden Anpassungen, dass sie kein gemeinsames Produkt mehr teilen, oder Leistungsvereinbarungen, die keinerlei Nachbarschaft dulden. Viele reife Plattformen enden in einem Hybridmodell: standardmäßig Multi-Tenant, mit verstärkter Isolation für die wenigen Fälle, die es rechtfertigen.

Wie wir es bei InAI angehen

Bei InAI bauen wir Produkte mit dieser Architektur als Fundament. Sowohl unser SaaS-Ecommerce als auch das KI-gestützte Content-CMS entstehen multi-tenant, wobei die kundenweise Isolation als eine Regel verstanden wird, die in der Datenschicht verteidigt und automatisch geprüft wird — nicht als Versprechen. Das Ziel ist einfach und unglamourös: dass jeder Kunde eine Plattform genießt, die sich für alle verbessert, ohne dass seine Informationen jemals die eines anderen kreuzen.

Es ist keine Magie und kein Marketing-Etikett. Es ist eine technische Entscheidung mit klaren Vorteilen und realen Kosten, und der Schlüssel liegt darin, diese Kosten von Tag eins an ehrlich zu tragen.