Multi-Tenant-Kern

Ein Multi-Tenant-Kern ist eine Plattform/Produkt-Basisschicht, die viele unabhängige Kunden (Tenanten) auf gemeinsamen Ressourcen mit garantierter Isolation, überschaubaren Limits und sicherer Anpassung bedient. Ein gut gestalteter Kern reduziert die TCO, beschleunigt das Onboarding, vereinfacht Freigaben und bietet jedem Mieter vorhersehbare Qualität.

1) Mietermodell und Isolationsgrenzen

Bestimmungen

Tenant (Tenant/Org/Account): Logische Organisation mit eigenen Benutzern, Daten, Richtlinien und Limits.
Isolation: Die Fähigkeit, den Einfluss eines Mieters auf die Daten, die Leistung und die Sicherheit eines anderen zu verhindern.

Isolationsstufen

1. Daten: einzelne DBs/Diagramme/Tabellen, Verschlüsselung mit „Mieterschlüssel“, Filter 'tenant _ id'.
2. Berechnungen: CPU/RAM/IO-Kontingente, Worker-Pool pro Tenant oder „gewichtete“ Warteschlangen.
3. Netzwerk: Segmentierung, private Endpunkte/VPNs, Berechtigungslisten nach Mieter.
4. Operationen: Migrationen, Backups, DRs und Vorfälle mit Expositionsgrenzen „pro Mieter“.

Muster der Multitenanz

Silo (harte Isolation): einzelne Cluster/DB pro Tenant. Maximale Sicherheit, hoher Preis.
Pool (gemeinsame Ressourcen): eine gemeinsame Infrastruktur mit logischer Isolierung; bessere Wirksamkeit, höheres Risiko von „noisy neighbor“.
Bridge/Hybrid: Hybrid - gemeinsame Steuerungsebene + selektiv „silo“ für VIP/regulierte Kunden.

2) Identifizierung und Weiterleitung von Mieteranfragen

Erlaubnis des Mieters (Tenant Resolution)

Nach Domain: 'https ://{ tenant} .example. com`

Unterwegs: „/t/{ tenant }/... “

Nach Überschrift: „X-Tenant-Id“, „X-Org“ (Signaturprüfung)

Durch Token: Stempel 'tenant _ id', 'org _ id', 'plan', 'scopes'

Routing

L7-Gateway (API-Gateway/Ingress) ruft 'tenant _ id' ab, bereichert den Kontext ('plan', Limits, Region), schreibt in Traces/Logs.
Funktionale Dienste akzeptieren einen schreibgeschützten Kontext; Entscheidungen über Route und Limits werden von der Gateway/Polisi Engine getroffen.

3) Daten und Schemata: Strategien

Speicheroptionen

Shared-Schema, Row-Level: Ein Satz Tabellen, Feld 'tenant _ id', strenge RLS (Row-Level Security).
Shared-DB, per-schema: ein DBMS, separates Schema pro Tenant; Balance zwischen Handling und Isolation.
Per-DB/Cluster: separate DB/Cluster je Tenant; teurer, einfacher für hoheitliche Forderungen.

Wichtige Praktiken

Überall explizit 'tenant _ id' übergeben und in zusammengesetzte Schlüssel/Indizes aufnehmen.
RLS/Zugriffsrichtlinien auf DBMS-Ebene + Service-Validierung durch „Double Lock“.
Verschlüsselung: Schlüsselhierarchie (root KMS → key-envelope pro Tenant → DEK pro Objekt).
Das Archiv/Retention und das „Recht auf Vergessen“ werden von Politikern auf Mieterebene verwaltet.

4) Einstellungen, Features und Versionen

Konfigurationen nach Tenant

Tabelle/Speicher 'tenant _ config' (Plan, Quoten, Ficha-Flags, Lokalisierung, SLA).
Config-Prioritäten: Standard → Plan → Tenant → Umgebung → Benutzer.
Caching Config mit kurzen TTL und Behinderung durch die Veranstaltung.

Ficha-Flags und Kompatibilität

Aktivierung von Funktionen punktuell (per-tenant/per-cohort), Kanarienrollen.
API-Versionierung: stabiler Vertrag + Adapter an der Grenze (back/forward-kompatible Formate).

5) Limits, Quoten und Abrechnung

Verbrauchspolitik

Rate limiting: 'requests/sec' per tenant/route, 'token-backet' mit den Prioritäten der Pläne.
Quotas: Speicherkapazität, Anzahl der Objekte, Nachrichten/min, Jobs/Stunde.
Fairness: „gewichteter Zeitplan“ der Warteschlangen + Isolierung der Worker für VIPs.

Abrechnung

Zähler nach 'tenant _ id' (usage-metrics) → Aggregatoren → Rechnungen.
Schnappschüsse an der Grenze (Idempotenz und Schutz vor Ereignisverlust).
Modelle: fester Plan + Nachkonsum, Post-Pei/Pre-Pei, „tiered“ Rabatte.

6) Sicherheit und Zugang

Authentifizierung/Autorisierung

OIDC/SAML mit den Stempeln 'tenant _ id', 'roles', 'scopes'.
RBAC/ABAC: Rollen auf Mieterebene (Owner/Admin/Reader), Projekt-/Abteilungsattribute.
Delegierter Zugriff (Service-to-Service) mit mTLS und eingeschränkten Token.

Grenzen des Vertrauens

Richtlinien für die Annahme von Anfragen: Überprüfung der Beschriftung von Titeln, Nonce/Timestamp, Bindung an die Quelle.
Geheimnisse und Schlüssel: Per-Tenant-Rotation, individuelle KMS-Kontexte, Audit von Schlüsseloperationen.
Multi-Region & Datenresidenz: Pinning des Tenants zur Region, gesteuert durch überregionale Ströme.

7) Beobachtbarkeit „nach Mietern“

Tracing und Metriken

Erforderliche Tags: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Dashboards und Alerts nach Segment (VIP/einstellbar/neu).

Protokolle und Prüfungen

Aktivitätsprotokolle (wer/was/wann/wo) mit unveränderlichem Speicher und Retention zur Mieterpolitik.
Pre-Aggregation von Ereignissen für billige Speicherung, Wiederherstellung von Details „per Klick“.

8) Leistung und „noisy neighbor“

Lärmschutzmaßnahmen

Grenzwerte für Warteschlangen/Worker, CPU-Shares und IO-Proportionen per tenant.
Trennung der Caches: Schlüsselpräfixe' tenant: {id}:...', TTL nach Plänen, Schutz vor „cache stampede“.
Indizes und Abfragepläne unter Berücksichtigung der Selektivität nach 'tenant _ id'.

Kaltstarts und „warme“ Pools

Vorwärmen für VIP/Peak-Fenster.
Elastische Worker-Pools durch metrische Signale (Backpressure/Auto-Scaling).

9) Updates und Migrationen ohne Ausfallzeiten

Strategie

Backward-kompatible Migrationen (expand → migrate → contract)

Migrationen „nach Mietern“: Batches mit Fortschrittskontrolle, „Pause/Rollback“ für eine bestimmte' tenant _ id'.
Sampling und „kanarische“ Migrationen auf einer Untergruppe von Mietern.

DR und Vorfälle

DR-Plan mit RTO/RPO per tenant; partieller „Read-Only-Modus“ ohne globale Downtime.
Isolierung des Vorfalls: Fusionieren durch 'tenant _ id', Löschen des „heißen“ Mieters betrifft die anderen nicht.

10) APIs und Protokolle

REST/gRPC mit obligatorischem Mieterkontext (in Stigmen/Überschriften).
Events (event-driven): Topics mit der Bezeichnung 'tenant. {id} .event', Filter und ACL für Abonnements.
Globale Einstiegspunkte: Das L7-Gateway validiert den Kontext, wendet Limits an und verschlüsselt die PII der Tenant-Richtlinie.

11) Lebenszyklus des Mieters

1. Provijining: Mietereintrag anlegen, Schlüssel/Config generieren, Region binden.
2. Aktivierung: Freigabe des OIDC/SAML-Clients, Erstellung von Rollen/Richtlinien, Primärkontingente.
3. Betrieb: Überwachung, Abrechnung, Flaggen-/Planaktualisierungen.
4. Suspend/Trottling: Einfrieren mit Datenspeicherung/Export.
5. Löschen/Exportieren: Retention, konservierte Backups, Krypto-Schlüssellöschung (Crypto-Shredding).

12) Mini-Referenzarchitektur (verbales Schema)

Edge (API-Gateway): TLS/mTLS, Extraktion 'tenant _ id', Limits, Audit.
Control Plane: Mieterkatalog, Configs, Ficha-Flaggen, Abrechnung, Politik.
Data Plane (Dienste): Stateless-Dienste, Warteschlangen, Worker mit Quoten; Redis/kv mit Tenant-Präfixen.
Speicher: RLS-DB/einzelne Schaltungen/DB; KMS mit Schlüssel pro Mieter; Objektspeicher mit Envelope-Verschlüsselung.
Observability: Tracing/Metriken/Logs mit dem Tag 'tenant _ id', alerts per plan.
Admin: isolierte Operationen (Migrationen/Backups) auf einer Teilmenge der Mieter.

13) Checkliste vor dem Verkauf

Einheitliche Methode zur Definition von 'tenant _ id' an der Grenze und in den Diensten.
RLS/ACL-Richtlinien werden durch Tests und „negative Szenarien“ getestet.
Quoten/Limits/Abrechnung werden unter realen Belastungen validiert; es gibt Schutz vor „Billing Drops“.
Beobachtbarkeit und SLO per tenant; Warnungen für VIP/einstellbar.
Migrationen sind kompatibel, es gibt partielle Rollbacks und Nachmieter-Batches.
DR-Szenarien mit RTO/RPO per tenant und regelmäßigen Übungen.
Verschlüsselung mit „Mieterschlüssel“, Rotation und Schlüsselaudit.
Dokumentation von API-Verträgen/Ereignissen und Versionsrichtlinien.

14) Typische Fehler

Globale Migrationen „auf einen Schlag“ ohne die Möglichkeit, einen problematischen Mieter zu stoppen.
Versteckte Abhängigkeit von 'tenant _ id' im Cache/Warteschlangen → Datenleck/Querung von Warteschlangen.
Kontexte mischen (Admin-Operationen zufällig ohne' tenant _ id').
Keine „Doppelverriegelung“: nur Service-Check ohne RLS in der DB.
Ein einziges Limit für den gesamten Cluster → „noisy neighbor“ und eine Verletzung von SLO.
Undurchsichtige Abrechnung ohne Idempotenz und Audit-Trail.

15) Schnelle Strategieauswahl

Strenge Isolierung/Regulierung: Silo (einzelne DBs/Cluster), Region-Lok.
Ausgewogene Effizienz: Shared-DB per schema + RLS, Schlüssel per tenant.
Hoher Echtzeitverkehr: gemeinsame Warteschlangen mit „gewichteten“ Quoten und engagierten Workern für VIPs.
Viele Anpassungen: Ficha-Flags + API-Adapter, Config-Speicher nach Priorität.

Schlussfolgerung

Der Multi-Tenant-Kern ist die Disziplin der Engineering-Grenzen: explizite Definition von 'tenant _ id', strikte Isolation auf allen Ebenen, überschaubare Quoten und transparente Abrechnung sowie Beobachtbarkeit und Kompatibilität von Releases. Wenn Sie den beschriebenen Mustern folgen, können Sie das Produkt skalieren, ohne die Sicherheit, Qualität und Änderungsgeschwindigkeit für jeden Mieter zu beeinträchtigen.