Mehrmandanten-Architektur: Wie wir skalieren
Ein praktischer Blick auf Mandantengrenzen, Skalierungsannahmen und Prüfungen vor einer hochvolumigen Einführung.
Der Aufbau einer SaaS-Plattform, die mehrere Unternehmen bedient, erfordert sorgfältige architektonische Entscheidungen. Bei LuniOps haben wir einen Mehrmandantenansatz auf Firebase-Basis gewählt, der starke Mandantentrennung durchsetzen soll und gleichzeitig die Betriebskosten überschaubar hält.
Jeder Mandant (Unternehmen) erhält einen mandantenbezogenen Datenbereich innerhalb von Firestore. Sicherheitsregeln und Quellcode-Verträge sind darauf ausgelegt, Nutzer auf Daten ihres Mandanten zu begrenzen; vor der Veröffentlichung braucht diese Grenze Emulator-, Code-Review- und Produktionsregel-Nachweise. Das praktische Ziel ist klar: Ein Nutzer von Unternehmen A soll über unterstützte App-Pfade keine Daten von Unternehmen B sehen oder ändern können.
Unser rollenbasiertes Zugriffskontrollsystem arbeitet sowohl auf Mandanten- als auch auf Modulebene. Jeder Mandant kann benutzerdefinierte Rollen mit granularen Berechtigungen definieren — beispielsweise kann ein Lagerleiter vollen Zugriff auf das Inventar haben, aber nur Lesezugriff auf Bestellungen.
Für Skalierung stellt Firebase verwaltete Infrastruktur bereit, aber hochvolumige Mandanten brauchen trotzdem Indexprüfung, Lesebudget-Prüfungen, lastbewusste Arbeitsabläufe und Monitoring. Ein Pilot sollte erwartetes Bestellvolumen, Exportgröße und Rollenmix validieren, bevor externe Performance- oder Kapazitätsaussagen genutzt werden.
Mandantenbezogene Export-, Sicherungs- und Migrationspfade können Betriebsrisiko reduzieren, beweisen aber nicht automatisch regulatorische Bereitschaft. Datenstandort, Aufbewahrung, Wiederherstellungsproben und kundenspezifische Vertragsanforderungen brauchen weiterhin Provider-Konfiguration, Rechtsprüfung und Produktionsnachweise.