Architektur

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-Service.