Dokumentation

Architektur

Multi-Tenant-Modell mit einer Datenbank, Postgres Row-Level Security und Modul-Toggles pro Mandant.

Architektur

DARION läuft als Single-Database-Multi-Tenant-SaaS. Alle Mandanten teilen sich eine Postgres-Instanz, die Datenisolation passiert über Row-Level Security in der Datenbank. Jede Tabelle führt eine tenant_id und jede Zeile gehört genau einem Mandanten.

Single-Database-Multi-Tenant

  • Eine Postgres-Instanz (Patroni 3-Node-HA) hält alle Mandanten.
  • Geteilte Schemas für alle Module, getrennt durch tenant_id pro Tabelle.
  • Geringe Betriebskosten, da kein Schema-pro-Mandant-Overhead.
  • Migrationen einmal für alle Mandanten.

Postgres Row-Level Security

Jede Tabelle hat eine RLS-Policy, die tenant_id = current_setting('app.tenant_id') prüft. Die Anwendung setzt diese Session-Variable bei jedem Request, bevor sie eine Query ausführt. Es ist technisch unmöglich, ohne gültige Tenant-ID Daten anderer Mandanten zu lesen.

Tenant-Kontext-Propagation

Browser → Cloudflare-Tunnel → Next.js (RSC)
                                  │
                                  ▼
                              FastAPI Backend
                                  │ setzt app.tenant_id
                                  ▼
                            Postgres mit RLS

Die Tenant-ID kommt aus dem Keycloak-Token. Die FastAPI-Middleware extrahiert sie und setzt sie als Postgres-Session-Variable, bevor die eigentliche Query läuft.

Modul-Toggles pro Mandant

Jeder Mandant hat eine Tabelle tenant_modules, die festlegt, welche Module aktiv sind. Der owner kann Module aktivieren oder deaktivieren (Berechtigungen).

  • 14 Standard-Module sind ab Tag 1 aktiv.
  • E-Rechnung ist Pflicht-Default (gesetzlich ab 2027 in DE).
  • Voice und Company-Modul sind opt-in mit Approval.

Wird ein Modul deaktiviert, bleiben die Daten als Snapshot lesbar. Quellen-Module sind nur nicht mehr schreibbar. So gehen keine Daten verloren, wenn ein Mandant ein Modul wieder abschaltet.

Berechtigungen auf Anwendungsebene

Innerhalb eines Mandanten greift zusätzlich das Rollensystem (owner, admin, member). Die Rollen werden im Backend gegen jede Aktion geprüft, unabhängig von der Datenbank-RLS. Mehr dazu in Berechtigungen.

Daten-Replikation und Backup

  • Patroni repliziert synchron zwischen drei Postgres-Nodes (1 Primary, 2 Replicas).
  • pgBackRest macht Off-Site-Backups auf C2-Storage in Frankfurt.
  • WORM-Retention 90 Tage für DSGVO- und NIS2-Konformität.
  • 3-2-1-1-0-Strategie: 3 Kopien, 2 Medien, 1 Off-Site, 1 immutable, 0 Fehler im letzten Restore-Test.

Sicherheits-Layer

  • Cilium NetworkPolicies zwischen Services im K3s-Cluster.
  • Keycloak für SSO, MFA und Tenant-Realm-Trennung.
  • Infisical für Secrets, nicht im Code.
  • MinIO SSE-KMS für verschlüsselten Object-Storage.

Verwandt