Sie bauen eine SaaS-Plattform für den deutschen Markt. Die Architekturentscheidungen jetzt bestimmen Ihren Erfolg.
Multi-Mandantenfähigkeit ist der Kern jeder SaaS-Plattform. Wie Sie Mandanten isolieren, Daten speichern und Compliance sicherstellen, beeinflusst Skalierbarkeit, Kosten und Vertrauen Ihrer Kunden.
Im deutschen Markt kommt eine Besonderheit dazu: DSGVO, NIS2 und die Erwartung deutscher Kunden, dass ihre Daten in Deutschland bleiben. Datensouveränität ist kein Feature, sondern Voraussetzung.
Drei Architekturmuster für Datenisolierung
Gemeinsame Datenbank, gemeinsames Schema
Alle Mandanten teilen sich eine Datenbank und ein Schema. Die Mandantenzuordnung erfolgt über eine Tenant-ID in jeder Tabelle.
Vorteile: niedrigste Kosten, einfachstes Deployment, effizienteste Ressourcennutzung.
Nachteile: höchstes Risiko für Datenvermischung. Ein Bug in einer WHERE-Klausel, und Mandant A sieht die Daten von Mandant B. Compliance-sensible Kunden (Banken, Gesundheitswesen) akzeptieren das oft nicht.
Gemeinsame Datenbank, separates Schema
Jeder Mandant hat sein eigenes Datenbankschema innerhalb derselben Datenbank-Instanz.
Bessere logische Trennung. Kein Risiko versehentlicher Datenvermischung durch fehlende WHERE-Klauseln. Migrationen sind allerdings aufwändiger: jedes Schema muss einzeln aktualisiert werden.
Separate Datenbank pro Mandant
Jeder Mandant hat seine eigene Datenbank-Instanz. Maximale Isolierung.
Vorteile: einfachste Compliance, einfachstes Backup pro Mandant, sauberste Datentrennung. Für Enterprise-Kunden und regulierte Branchen oft die einzig akzeptable Option.
Nachteile: höhere Infrastrukturkosten, komplexere Verwaltung. Bei tausenden Mandanten wird das Datenbankmanagement zur eigenen Disziplin.
Was der deutsche Markt erwartet
Deutsche Unternehmen fragen bei SaaS-Evaluierungen drei Dinge: Wo liegen meine Daten? Wer hat Zugriff? Wie sind sie isoliert?
Hosting in Deutschland ist für viele deutsche Kunden ein Muss. Nicht nur aus Überzeugung, sondern aus regulatorischer Notwendigkeit. NIS2-regulierte Unternehmen müssen nachweisen, wo ihre Daten verarbeitet werden.
Deutsche Cloud-Anbieter im Vergleich bieten dafür verschiedene Optionen. Hetzner, IONOS oder die Open Telekom Cloud erfüllen die strengsten Anforderungen.
DSGVO-Konformität in der Multi-Mandanten-Architektur
Jeder Mandant ist ein eigener Verantwortlicher im Sinne der DSGVO. Sie als SaaS-Betreiber sind Auftragsverarbeiter. Das hat architektonische Konsequenzen.
Löschung pro Mandant: Wenn ein Mandant kündigt, müssen Sie alle seine Daten löschen können. Vollständig. Aus Datenbank, Backups und Logs.
Datenportabilität: Jeder Mandant muss seine Daten in einem maschinenlesbaren Format exportieren können. Artikel 20 DSGVO.
Audit-Trails pro Mandant: Wer hat wann auf welche Daten zugegriffen? Getrennt nach Mandant.
Mehr zu DSGVO-konformer Architektur in unserem DSGVO-Softwareleitfaden.
Authentifizierung und Autorisierung
SSO (Single Sign-On) ist für Enterprise-Kunden im deutschen Markt Standard. Unterstützen Sie SAML 2.0 und OpenID Connect von Anfang an.
Rollenbasierte Zugangskontrolle (RBAC) innerhalb jedes Mandanten. Der Admin eines Mandanten kann Rollen und Berechtigungen für sein Team verwalten. Aber: kein Zugriff auf andere Mandanten. Niemals.
API-Key-Management pro Mandant. Wenn Sie eine API anbieten, muss jeder Mandant eigene API-Keys verwalten können. Rate Limiting pro Mandant verhindert, dass ein Mandant die Plattform für alle anderen lahmlegt.
Billing und Preismodelle
Deutsche Kunden erwarten Rechnungen in Euro, mit deutscher Umsatzsteuer, mit korrekter Rechnungsadresse. Klingt trivial. Ist es nicht, wenn Sie 500 Mandanten in drei Preismodellen bedienen.
Stripe funktioniert technisch gut, hat aber seinen Sitz in den USA. Für maximale Compliance: Stripe mit europäischem Entity oder deutsche Alternativen wie Mollie oder GoCardless.
Preismodelle für den deutschen Markt: Seat-basiert (pro Nutzer) ist am verständlichsten. Nutzungsbasiert funktioniert bei technischen Produkten. Freemium ist in Deutschland weniger verbreitet als im US-Markt.
Skalierung und Noisy-Neighbor-Problem
Wenn ein Mandant ungewöhnlich viel Last erzeugt, darf das andere Mandanten nicht beeinträchtigen. Tenant-aware Caching, Connection Pooling und Rate Limiting sind Pflicht.
Horizontale Skalierung über Kubernetes oder vergleichbare Container-Orchestrierung. Auto-Scaling nach Last, nicht nach Mandantenanzahl.
Für den deutschen Markt gilt: Skalierung innerhalb deutscher oder europäischer Cloud-Regionen. Den übergreifenden Architekturkontext liefert unser Digitalisierungsleitfaden.
Sie bauen eine SaaS-Plattform für den deutschen Markt? Vereinbaren Sie ein Erstgespräch. Wir haben Multi-Mandanten-Systeme von null auf tausende Nutzer gebaut und kennen die regulatorischen Anforderungen.
