# ArchitekturEvent-getriebene, multi-tenant, ML-erweiterte Entscheidungs-Plattform — wie sie strukturiert ist.

## Pipeline-Übersicht

```
Stream-Ingest → Feature-Validatoren → Persistenz
                                        ↓
                                  Event-Bus (PG LISTEN/NOTIFY)
                                        ↓
                            ┌──────────────────┐
                            │ Decision-Daemon  │ (pro Mandant Config)
                            └────────┬─────────┘
                                     ↓
                              Validierte Aktion
                                     ↓
                              Outcome-Feedback
                                     ↓
                            Modell-Training / Tuning
```

Die Plattform verwandelt rohe Datenströme über eine bewusst
gestaffelte Pipeline in konvergente Entscheidungen. Jede Stufe
hat eine einzelne Verantwortlichkeit und emittiert durable Events
für die nächste.

## Event-getriebener Kern

- **Event-Bus.** PostgreSQL `LISTEN/NOTIFY` transportiert Events
  zwischen Daemons. Events werden in einer durable Tabelle
  persistiert, nicht nur broadcasted — Consumer können nach einem
  Reconnect von einem Cursor aus replayen.
- **At-least-once-Delivery.** Consumer bestätigen verarbeitete
  Events. Unbestätigte Events werden nach Timeout neu zugestellt.
  Idempotenz ist die Verantwortung des Consumers.
- **Cursor-tracked Replay.** Jeder Consumer hält seinen eigenen
  Cursor. Nach einer Disconnect-Phase setzt er da fort, wo er
  aufgehört hat — keine Events gehen verloren, keine werden über
  die konfigurierten Retry-Semantiken hinaus doppelt verarbeitet.

## ML-Pipeline

- **Modelle.** XGBoost auf historischen Features trainiert, mit
  ONNX Runtime für Inference (2–5× schneller als das
  Training-Framework).
- **Outputs.** Modelle klassifizieren Regime in drei Dimensionen
  — Richtung, Volatilität, Qualität. Keine spekulativen
  Punktprognosen.
- **Hyperparameter-Tuning.** Optuna mit Walk-Forward-Holdout,
  Champion-/Challenger-Waves, Quality-Gates.
- **Feedback-Loop.** Das Outcome jeder Entscheidung wird
  protokolliert und in die nächste Tuning-Runde zurückgespielt.

## Multi-Tenant-Modell

Mandanten-Isolation wird auf zwei Ebenen durchgesetzt:

- **Stored Procedures.** Alle mandantenseitigen Operationen
  laufen über Stored Procedures, die Ownership durchsetzen.
  Direkte Tabellen-Writes durch Tenant-Code sind nicht erlaubt.
- **Row-Level Security.** Postgres-RLS als harter Backstop.
  Selbst wenn die Anwendungslogik einen Bug hat, verhindert RLS
  Cross-Tenant-Datenzugriff.

Pro-Mandanten-Konfiguration umfasst:

- **Schlüssel und Rate-Limits.**
- **Kill-Switch.** Operator-Override, um einen Mandanten ohne
  Redeploy sofort zu deaktivieren.
- **Risiko-Profil.** Schwellwertparameter pro Entscheidungsklasse.

## Validatoren

Drei Stellen, an denen Validierung stattfindet:

1. **Vor der Persistenz.** Stream-Events, die die Validierung
   nicht bestehen, werden markiert, nicht still gedroppt.
   Operatoren sehen sie im Dashboard.
2. **Vor dem Modell-Training.** Features fürs Training werden
   gegen das Schema neu validiert. Drift triggert einen Alert,
   bevor Modelle nachtrainiert werden.
3. **Zur Laufzeit.** Feature-Validatoren laufen kontinuierlich mit
   `DATAMISSING`-Auto-Recovery — wenn ein erwartetes Feature
   fehlt, fällt der Daemon auf einen dokumentierten Default
   zurück und feuert ein strukturiertes Event ab.

## Observability

- **21 Live-Dashboards.** Heartbeat, Latenz, Drift-Detection,
  Entscheidungs-Verteilung, Mandanten-Volumen.
- **Strukturiertes Logging.** Konsole, Datei und Datenbank —
  dieselben Log-Events aus allen dreien per gleichem Query
  lesbar.
- **Health-Monitoring.** Jeder Daemon emittiert Health-Events in
  einer festen Kadenz. Fehlende Events triggern Pages.

## Produktionsreife-Mechanismen

- **Circuit Breaker** pro Datenquelle — Ausfälle degradieren
  graceful statt zu kaskadieren.
- **E-Mail- und XMPP-Alerting** für operatorrelevante Events.
- **Universal config-driven Defaults.** Datenquellen-Mappings,
  Fallback-Ketten, Einheits-Konvertierungen, Schwellwerte — alle
  in JSON. Keine Magic Numbers im Code.
- **Prozess-Isolation** via tmux + Devuan — Daemons können
  einzeln neu gestartet werden ohne sich abzustimmen.

## Was das nicht ist

- Keine Kubernetes-Style-Autoscaling-Plattform. Das läuft auf
  einer kleinen Anzahl gut verstandener Maschinen mit bewusster
  Daemon-Platzierung.
- Keine „aufsetzen und vergessen"-Lösung. Token-Sets,
  Modell-Versionen, Tenant-Configs und Dashboards brauchen
  Operator-Aufmerksamkeit.
- Nicht generisch. Die Plattform spiegelt eine spezifische
  Klasse von Hochfrequenz-Entscheidungs-Problemen — die Anpassung
  an einen sehr anderen Workload ist der
  [Entwicklung](/de/services/development/)-Service.