meldestelle/docs/03_Development/Backend/Multi_Tenant_Kurz.md

type, status, owner, last_update

type	status	owner	last_update
Reference	ACTIVE	Lead Architect	2026-04-03

Tenant-Isolation & Multi‑Tenant (Kurzfassung)

Vollständige Entscheidung: ADR‑0021: Tenant‑Resolution‑Strategie (Schema‑per‑Tenant).

Kernaussagen

• Eine Veranstaltung = ein Tenant = ein Datenbankschema (Schema‑per‑Tenant).
• Requests tragen X-Event-Id; Backend validiert gegen control.tenants und schaltet das Schema je Request.
• Flyway führt Migrationen je Tenant‑Schema aus (eigene flyway_schema_history).
• Stammdaten (Reiter/Pferde/Vereine/Funktionäre) sind global und nicht tenant‑spezifisch; Entries/Kassa sind tenant‑lokal.

Umsetzung (Kurz)

• Web‑Layer: TenantWebFilter (Spring) bzw. Plugin (Ktor) liest X-Event-Id und legt TenantContext ab.
• Persistence: SCHEMA‑Multitenancy (SET search_path) oder Hibernate‑MultiTenantConnectionProvider.
• Registry: control.tenants(event_id, schema_name, status, db_url?, version, created_at).

Betroffene Bereiche

• Datenmodell tenant‑lokal: veranstaltungen, turniere, bewerbe, abteilungen, teilnehmer_konten, turnier_kassa (siehe Datenbankschema).
• Services: Der Entries‑Service arbeitet mandantenfähig; andere Services bleiben Single‑Tenant/global (vgl. Backend‑Roadmap).