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

# Tenant-Isolation & Multi‑Tenant (Kurzfassung)

Vollständige Entscheidung: [ADR‑0021: Tenant‑Resolution‑Strategie (Schema‑per‑Tenant)](../01_Architecture/adr/0021-tenant-resolution-strategy-de.md).

## 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](./Schema/Database_Schema_V1-V009.md)).
- Services: Der Entries‑Service arbeitet mandantenfähig; andere Services bleiben Single‑Tenant/global (vgl. Backend‑Roadmap).