MicrocosmWorksInnovation und Architektur digitaler Kosmen
Über unsKontakt
MicrocosmWorksInnovieren und Gestalten digitaler Kosmen

Bereitstellung von IT-Lösungen, die zählen. Wir sind leidenschaftlich für Technologie, Sicherheit und helfen Unternehmen, durch zuverlässige, innovative IT-Infrastruktur zu wachsen.

[email protected]
+91 7011868196
New Delhi, India

AI Wachstumszentrum

AI HubStartup-InnovationUnternehmensbeschleuniger

Lösungen

Alle LösungenWellness- & Fitness-AppsAI Video PlattformAI Agent Entwicklung

Ressourcen

EinblickeBranchenleitfädenAnwendungsfall-BlaupausenArchitektur-MusterFallstudien

Unternehmen

Über unsKontaktUnsere Arbeit

Dienstleistungen

Digitale BeratungCloud-InfrastrukturSaaS-EntwicklungKI-EntwicklungVideotechnologie
ERP-EntwicklungZoho-AnpassungOdoo-EntwicklungSalesforce-IntegrationBenutzerdefinierte CRM-Entwicklung
QuickBooks-IntegrationIoT-LösungenBlockchain-Entwicklung
Cybersecurity-BeratungIT-Support - L3

© 2026 MicrocosmWorks. Alle Rechte vorbehalten.

DatenschutzrichtlinieNutzungsbedingungen
Zurück zu Architekturmustern
ApplicationAdvanced

Multi-Tenant SaaS-Architektur

Eine Codebasis, Hunderte von Mandanten, keine Datenlecks — das Fundament jedes skalierbaren SaaS-Unternehmens.

June 22, 2026
|
3 topics covered
Diskutieren Sie diese Architektur
multi-tenant-saas-architecture.webp
Application
Category
Advanced
Complexity
Gesundheitswesen, EdTech
Industries
3+
Technologies

Wann Sie dies benötigen

Sie erstellen eine Plattform, die mehrere Kunden von einer einzigen Bereitstellung aus bedient. Jeder Kunde erwartet isolierte Daten, markengerechte Erlebnisse und eine mandantenspezifische Abrechnung – aber Sie können es sich nicht leisten, für jeden eine separate Infrastruktur zu betreiben. Sie benötigen die Wirtschaftlichkeit einer geteilten Infrastruktur mit den Isolationsgarantien dedizierter Systeme. Dies ist die grundlegende Spannung der SaaS-Architektur, und ein frühzeitiger Fehler im Isolationsmodell ist einer der teuersten Fehler bei der Plattformentwicklung.

Related Architecture Patterns

Explore more design patterns and system architectures

event-driven-microservices.webp
Application

Ereignisgesteuerte Microservices

Entkoppeln Sie alles. Lassen Sie Dienste über Ereignisse kommunizieren, nicht über Erwartungen an die Verfügbarkeit des jeweils anderen.

EnterpriseView
ai-ml-pipeline-architecture.webp

Benötigen Sie Hilfe bei der Implementierung dieser Architektur?

Unsere Architekten können Ihnen helfen, Systeme mit diesem Muster für Ihre spezifischen Anforderungen zu entwerfen und zu erstellen.

Kontakt aufnehmen

Musterübersicht

Multi-Tenant SaaS-Architektur bietet eine logische oder physische Trennung zwischen Mandanten, während zugrunde liegende Compute-, Storage- und Netzwerkressourcen gemeinsam genutzt werden. Das Muster umfasst Mandanten-Provisioning, Datenisolation, Feature-Management, Abrechnungsmessung und White-Label-Anpassung. Die zentrale Designentscheidung ist das Isolationsmodell: geteilte Datenbank mit Row-Level Security, Schema-pro-Mandant oder Datenbank-pro-Mandant. Jedes Modell wägt Isolationsstärke gegen operative Komplexität und Kosteneffizienz ab.

Referenzarchitektur

Das System ist in drei Schichten organisiert. Das mandantenfähige Gateway übernimmt die Authentifizierung, die Mandantenauflösung (via Subdomain, JWT Claim oder API Key) und das Request-Routing. Die Anwendungsschicht arbeitet vollständig im Mandantenkontext — jede Abfrage, jeder Cache Key, jede Queue-Nachricht ist auf den aufgelösten Mandanten zugeschnitten. Die Datenschicht erzwingt die Isolation auf Speicherebene durch Row-Level Security Policies, Connection Pooling pro Mandant und verschlüsselte Partitionierung im Ruhezustand.

Kernkomponenten
  • Mandantenverwaltungsdienst: Verwaltet Provisioning, Onboarding-Workflows, benutzerdefinierte Domain-Zuordnung, Theme-/Branding-Konfiguration und mandantenspezifische Feature Flags. Stellt eine interne API für Mandanten-Lebenszyklus-Ereignisse (erstellt, suspendiert, gelöscht) bereit
  • Mandantenkontext-Propagator: Middleware, die die Mandantenidentität aus der Anfrage (Subdomain, JWT, Header) auflöst und den Mandantenkontext in jeden nachgeschalteten Aufruf injiziert — Datenbankverbindungen, Cache Keys, Queue-Nachrichten, Log-Einträge
  • Datenisolations-Engine: Implementiert das gewählte Isolationsmodell. Für RLS: PostgreSQL Policies, die jede Abfrage nach tenant_id filtern. Für Schema-pro-Mandant: dynamisches Verbindungs-Routing mit Connection Pool Management. Für Datenbank-pro-Mandant: Provisioning-Automatisierung mit Terraform/Pulumi
  • Abrechnungs- & Messdienst: Ereignisgesteuerte Nutzungsverfolgung mit mandantenspezifischer Aggregation. Integriert sich mit Stripe Connect oder benutzerdefinierten Abrechnungs-Engines. Unterstützt mehrere Preismodelle (pro-Sitz, nutzungsbasiert, gestaffelt, hybrid)

Designentscheidungen & Kompromisse

RLS vs. Schema-pro-Mandant vs. Datenbank-pro-Mandant
MW verwendet standardmäßig RLS (geteilte Datenbank, Row-Level Security) für die meisten SaaS-Produkte. Es ist am einfachsten zu betreiben — ein Migrationspfad, ein Connection Pool, eine Backup-Strategie. Schema-pro-Mandant ist sinnvoll, wenn Mandanten benutzerdefinierte Schemaerweiterungen benötigen (selten) oder wenn regulatorische Anforderungen eine nachweisbare Isolation verlangen. Datenbank-pro-Mandant ist für Enterprise-Deals reserviert, bei denen der Kunde vertraglich eine dedizierte Infrastruktur benötigt. Wir haben alle drei implementiert — die Wahl hängt von Ihrer Compliance-Haltung und der Mandantenzahl ab.
Subdomain vs. Pfadbasierte Mandantenauflösung
Subdomains (acme.yourapp.com) sind für White-Label-Produkte sauberer und ermöglichen mandantenspezifische TLS-Zertifikate. Pfadbasierte Lösungen (yourapp.com/acme/) sind einfacher zu implementieren und vermeiden die Komplexität von Wildcard-DNS. MW empfiehlt die Subdomain-Auflösung für B2B SaaS mit White-Label-Anforderungen, pfadbasierte für interne Multi-Tenant-Tools.
Geteilte Feature Flags vs. Mandantenspezifische Konfiguration
Wir verwenden ein zweischichtiges Feature-Flag-System: Globale Flags steuern die Einführung über die gesamte Plattform hinweg, während Overrides auf Mandantenebene es ermöglichen, Beta-Funktionen für bestimmte Kunden zu aktivieren oder Funktionen für Mandanten mit niedrigeren Tarifen zu deaktivieren. Edge Config oder LaunchDarkly unterstützt dies mit Sub-Millisekunden-Lesezeiten.
Mandantenfähiges Caching
Jeder Cache Key muss auf tenant_id beschränkt sein. Das klingt offensichtlich, aber Cache Key Kollisionen über Mandanten hinweg sind eine der häufigsten Multi-Tenant-Bugs. Wir setzen dies durch eine Cache Key Factory durch, die den Mandantenkontext automatisch präfigiert.
Multi-Tenant SaaS-Architektur - System Architecture Diagram

System Architecture Overview

Technologieauswahl

SchichtTechnologien
ComputingNode.js (NestJS), Python (FastAPI), containerized on ECS Fargate or Kubernetes
DatenPostgreSQL with RLS, Redis (tenant-scoped), S3 (tenant-partitioned buckets)
IdentitätClerk, Auth0, or Okta with tenant-scoped organizations
AbrechnungStripe Connect (marketplace model), Stripe Billing (metered subscriptions)
BeobachtbarkeitDatadog with tenant-dimension tags, structured logging with tenant_id on every entry

Wann zu verwenden / Wann zu vermeiden

Verwenden Sie, wennVermeiden Sie, wenn
Eine B2B-Plattform erstellt wird, die 10+ Kunden von einer geteilten Infrastruktur aus bedientJeder Kunde eine vollständig dedizierte Infrastruktur benötigt (Compliance/vertraglich)
Sie White-Label-Branding, benutzerdefinierte Domains und mandantenspezifische Feature-Kontrolle benötigenSie weniger als 3 Kunden haben — eine einfachere Bereitstellung pro Kunde könnte ausreichen
Nutzungsbasierte oder gestaffelte Preisgestaltung eine mandantenspezifische Abrechnung erfordertDas Produkt eine Consumer-App mit Benutzerkonten ist, nicht organisationsbasierte Mandanten
Sie eine Deployment Pipeline, einen Monitoring Stack und eine On-Call Rotation möchtenMandanten grundlegend unterschiedliche Schemata oder Geschäftslogik haben (nicht nur Konfiguration)

Unser Ansatz

MW behandelt Multi-Tenancy als Querschnittsanliegen, nicht als Feature. Wir implementieren die Mandantenkontext-Propagation auf Middleware-Ebene, sodass Anwendungscode niemals manuell nach Mandanten filtert – dies wird vom Framework erzwungen. Unsere RLS-Implementierungen umfassen automatisierte Testsuiten, die bei jedem CI-Lauf versuchen, auf mandantenübergreifende Daten zuzugreifen. Wir haben Multi-Tenant-Plattformen entwickelt, die über 500 Mandanten auf geteilter Infrastruktur ohne Datenlecks bedienen, und wir haben Single-Tenant-Monolithen mithilfe des Stranglers-Fig-Musters auf Multi-Tenant-Architekturen migriert.

Verwandte Blueprints

  • Multi-Tenant Wellness Coaching SaaS — RLS Isolation mit White-Label-Branding für Coaching-Unternehmen
  • AI-Driven Personalized Learning Platform — Multi-Tenant EdTech mit mandantenspezifischen Inhaltsbibliotheken
  • Event Management & Ticketing Platform — Mandant pro Veranstalter mit Echtzeit-Ticketing
  • Multi-Tenant Billing & Subscription Engine — Das Abrechnungs-Backbone für Multi-Tenant-Plattformen

Verwandte Fallstudien

  • VR Training Multi-Tenant SaaS — Multi-Tenant-Plattform mit mandantenspezifischen VR-Inhalten und Analysen
  • AI Chat Platform — Multi-Model Chat SaaS mit mandantenspezifischem API Key Management und GDPR-Konformität
Related Technologies
SaaS-EntwicklungCloud-LösungenAI-Entwicklung
AI / Data

AI/ML Pipeline-Architektur

Modelle laufen nicht von allein. Die Pipeline, die Ihre Modelle trainiert, validiert, bereitstellt und überwacht, ist das eigentliche Produkt – das Modell ist nur ein Artefakt.

EnterpriseView
cloud-native-infrastructure.webp
Infrastructure

Cloud-native Infrastruktur

Infrastruktur, die wie Anwendungscode versioniert, getestet und bereitgestellt wird – denn Ihre Plattform ist nur so zuverlässig wie das, was ihr zugrunde liegt.

EnterpriseView

Häufig gestellte Fragen

Die optimale Wahl hängt von Ihren Anforderungen an die Mandantenisolation und den Umfang ab. MicrocosmWorks empfiehlt in der Regel einen Shared-Database-, Separate-Schema-Ansatz für die meisten B2B SaaS-Produkte, da dieser Kosteneffizienz mit Datenisolation in Einklang bringt, obwohl wir für Kunden in regulierten Branchen wie dem Gesundheitswesen oder der Finanzwirtschaft, wo eine strikte Datentrennung vorgeschrieben ist, eine Datenbank pro Mandant implementieren. Unsere Architekten bewerten Ihre Compliance-Anforderungen, die erwartete Anzahl von Mandanten und Abfragemuster, bevor sie das richtige Tenancy-Modell empfehlen.

MicrocosmWorks implementiert mandantenbewusstes Rate Limiting, Connection Pooling mit Pro-Mandanten-Quoten und Ressourcenisolation auf der Compute-Schicht, um „noisy-neighbor“-Probleme zu verhindern. Wir verwenden Techniken wie Weighted Fair Queuing und mandantenspezifische Caching-Tiers, damit ein plötzlicher Anstieg bei einem Kunden nicht zu Latenzzeiten für andere führt. Für Enterprise-Tier-Mandanten können wir dedizierte Compute-Partitionen bereitstellen, während die Shared Control Plane intakt bleibt.

MicrocosmWorks bietet Architekturdesign- und Implementierungsdienstleistungen zu Beratungssätzen zwischen 15 und 45 $/Stunde, abhängig von der Komplexität und der erforderlichen Seniorität des Teams. Ein typisches Multi-Tenant SaaS-Architekturprojekt – das Datenbankdesign, Mandantenisolation, Authentifizierung und Deployment Pipelines umfasst – dauert 8-16 Wochen mit einem funktionsübergreifenden Team. Wir kalkulieren jedes Projekt mit einer Festpreis-Discovery-Phase, damit Sie die volle Kostentransparenz haben, bevor Sie sich für den Bau entscheiden.

MicrocosmWorks entwickelt automatisierte Mandanten-Provisioning-Pipelines, die die Schemaerstellung, DNS-Konfiguration, Feature Flag-Initialisierung und Seed Data-Bereitstellung innerhalb von Minuten nach einer neuen Registrierung handhaben. Wir verwenden Infrastructure-as-Code-Tools wie Terraform oder Pulumi in Kombination mit ereignisgesteuerten Workflows, sodass jeder neue Mandant eine vollständig konfigurierte Umgebung ohne manuelles Eingreifen erhält. Dieser Ansatz ermöglicht es unseren Kunden, von 10 auf 10.000 Mandanten zu skalieren, ohne den Onboarding-Prozess zu ändern.

MicrocosmWorks implementiert eine konfigurationsgesteuerte Anpassungsebene unter Verwendung von Feature Flags, mandantenspezifischen Metadaten und einer Plugin-Architektur, die ein mandantenbezogenes Verhalten ohne Code-Branching ermöglicht. Wir gestalten Erweiterungspunkte auf den UI-Theming-, Workflow-Engine- und Integrationsschichten, sodass Mandanten ein einzigartiges Branding, Geschäftsregeln und Drittanbieterverbindungen haben können, die alle über Konfiguration verwaltet werden. Dies ermöglicht Ihrem Engineering-Team, eine einzige Codebasis zu pflegen und gleichzeitig vielfältige Kundenanforderungen zu unterstützen.