Realtime

Kurzzusammenfassung

• Realtime-Inferenz bedient interaktive Use-Cases mit niedriger Latenz und kontrolliertem Fehlverhalten.
• API-Verträge, Latenzziele und Schutzmechanismen sind für den produktiven Handshake verbindlich.
• Fehler werden deterministisch in Codes und Fallback-Pfade übersetzt.
• Wiederanlauf bedeutet hier Service-Recovery ohne Vertragsbruch für Konsumenten.

Zweck

Niedrig-latente Inferenz über API für zeitkritische Konsumenten mit nachvollziehbarer Versionierung.

BPMN-Kontext

• IDs: ServiceTask_Scoring
• Input-Bezug: Anfragepayload, modellkompatible Features, Auth-Kontext.
• Entscheidungsbezug: Antwort, degradiertes Verhalten oder harte Ablehnung je Validierung/SLO.
• Output-Bezug: Score-Antwort inkl. Modell-/Trace-Referenz für Downstream-Entscheidungen.

Eingabe-/Ausgabe-Vertrag

Request

• request_id (idempotency key, Pflicht)
• entity_context (fachliche Schlüsselattribute)
• feature_vector oder feature_ref
• as_of_ts (UTC)

Response

• request_id
• score
• model_version
• decision_support_only (immer true)
• trace_id
• latency_ms

SLA/SLO

• SLA: Verfügbarkeit 99.9% pro Kalendermonat.
• SLO:
  • p95 Latenz ≤ 250 ms
  • p99 Latenz ≤ 500 ms
  • Fehlerquote (5xx) < 0.5%

Fehlerbehandlung

HTTP-Klasse	Bedeutung	Aktion
4xx	Vertrags-/Auth-Fehler	Kein Retry durch Client, Payload korrigieren
429	Rate Limit erreicht	Backoff + Retry nach Retry-After
5xx	Temporärer Serverfehler	Max. 3 Retries mit Jitter
503	Geplanter/ungeplanter Degraded Mode	Fallback-Modell oder letzte gültige Antwort

Wiederanlaufregeln

1. Requests sind über request_id idempotent.
2. Bei Deployment-Rolling-Recovery darf kein inkompatibles Antwortschema ausgeliefert werden.
3. Nach Incident wird erst nach bestandenem Smoke-Test wieder auf 100% Traffic skaliert.
4. Falls Fallback aktiv war, muss ein fallback_used-Flag im Audit-Log gesetzt werden.

Entscheidung

• API-Vertrag versioniert und rückwärtskompatibel.
• Latenz- und Verfügbarkeits-SLOs mit Alerting aktiv.
• Degraded-/Fallback-Verhalten dokumentiert und getestet.