Webhook vs. Kafka vs. SQS vs. Postgres als Auslöser für KI-Agenten

Webhook, Apache Kafka, AWS SQS und Postgres LISTEN/NOTIFY beantworten dieselbe Frage im Produktivbetrieb: Wie löst ein externes Ereignis eine KI-Agentenausführung aus? Die Wahl hängt von Zustellung, Reihenfolge, erneuter Verarbeitung, Rückstaukontrolle und Antwortlatenz ab. Dieser Vergleich beschränkt sich auf eingehende Auslöser; die ausgehende Ergebniszustellung und MCP-Tool-Aufrufe sind separate Entscheidungen.

Vier eingehende Wege zur selben Agentenausführung

Alle vier sind eingehende Verbindungen: Ein externes Ereignis trifft ein, Connic verarbeitet es und startet für jeden verknüpften Agenten eine Ausführung mit den Nutzdaten. Die Verbindungsebene empfängt das Ereignis, authentifiziert die Quelle und übernimmt Wiederholungsversuche oder Pufferung, sofern das Protokoll dies unterstützt. Der Agent bleibt unverändert, während sich die Anbindung an die Ereignisquelle ändert. Unterschiede zwischen eingehender, ausgehender und synchroner Verarbeitung.

Webhook: synchroner HTTP-Push

Eine Webhook-Verbindung stellt dem Agenten eine URL bereit. Jeder Dienst, der eine HTTP-Anfrage senden kann, startet per POST eine Ausführung für jeden verknüpften Agenten. Die Authentifizierung erfolgt mit einem gemeinsamen Secret im Header X-Connic-Secret. Dies ist der direkte HTTP-Weg und der einzige, der ein Ergebnis unmittelbar zurückgeben kann: Im Sync-Modus wartet die Anfrage, bis die Ausführung abgeschlossen ist, und gibt deren Ausgabe zurück. Das eignet sich für eine Chat-UI oder einen synchronen API-Aufruf.

curl -X POST "<webhook-url>" \
  -H "X-Connic-Secret: <your-secret-key>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": "12345", "action": "review"}'

Bis Connic die Anfrage annimmt, liegt die Zustellung beim Aufrufer: Transportfehler und Anfragen mit Fehlerantworten müssen erneut gesendet werden. Im eingehenden Modus enthält eine erfolgreiche Antwort die IDs der von Connic erstellten Ausführungen. Diese IDs müssen auf Fehler bei der Übergabe oder Ausführung überwacht werden; die HTTP-Antwort beweist nicht, dass die Übergabe an die Warteschlange erfolgreich war. Die Quelle hat weiterhin weder ein dauerhaftes Ereignisprotokoll noch eine Reihenfolge zwischen parallelen Aufrufen. Ein Aufrufer, der Anfragen erneut sendet, sollte eine stabile Ereignis-ID oder einen Idempotenzschlüssel senden. Der empfangende Agent oder das Tool muss verarbeitete IDs speichern und vor einer erneuten Nebenwirkung prüfen; die Webhook-Verbindung dedupliziert keine beliebigen Nutzdaten. Webhook Sync einrichten und Signaturprüfung für Outbound konfigurieren.

Apache Kafka: Streaming-Consumer

Eine Kafka-Verbindung abonniert als Consumer ein Topic und startet für jede Nachricht eine Ausführung pro verknüpftem Agenten. Der vollständige Kafka-Kontext aus Topic, Partition, Offset und Key steht im Feld _kafka. Als dauerhaftes, geordnetes Log bewahrt Kafka die Reihenfolge innerhalb einer Partition und kann gespeicherte Historie mit einer neuen Consumer-Gruppe ab dem frühesten Offset erneut abspielen. Connic bestätigt den Offset, nachdem für jeden verknüpften Agenten eine Ausführung erstellt wurde. Ein Neustart vor dieser Bestätigung kann die Nachricht erneut zustellen und eine bereits erstellte Ausführung duplizieren. Nach der Bestätigung führt ein Fehler der erstellten Ausführung vor oder während der Verarbeitung dagegen nicht zu einer erneuten Zustellung durch Kafka.

{
  "order_id": "12345",
  "customer": "john@example.com",
  "items": ["widget-a", "widget-b"],
  "_kafka": {
    "topic": "orders",
    "partition": 0,
    "offset": 1542,
    "key": "order-12345"
  }
}

Consumer mit derselben Gruppen-ID teilen die Partitionen untereinander auf. Separate Gruppen-IDs konsumieren denselben gespeicherten Stream unabhängig voneinander. Innerhalb von Connic verteilt eine Verbindung jede Nachricht an alle verknüpften Agenten. Kafka ist die richtige Wahl für Teams, die es bereits betreiben, hohen Durchsatz haben oder Reihenfolge und erneute Verarbeitung benötigen. Der Preis ist operativer Aufwand: Kafka benötigt einen Cluster, auf dem die Verbindung als Consumer läuft. Kafka-Verbindung konfigurieren.

Postgres LISTEN/NOTIFY: Push direkt aus der Datenbank

Ist das relevante Ereignis eine Änderung in einer Datenbank, ist möglicherweise keine Warteschlange nötig. Die Postgres-Verbindung öffnet eine persistente Verbindung und lauscht auf einem Kanal. Bei einer Änderung an Zeilen ruft ein Trigger pg_notify auf, und jede Benachrichtigung startet eine Ausführung für jeden verknüpften Agenten. Es gibt weder Polling noch zusätzliche Infrastruktur: Die vorhandene Datenbank wird zur Ereignisquelle.

-- Notify the agent whenever a customer row is inserted
CREATE OR REPLACE FUNCTION notify_new_customer()
RETURNS TRIGGER AS $$
BEGIN
  PERFORM pg_notify(
    'new_customers',
    json_build_object('customer_id', NEW.id)::text
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER customer_insert_trigger
  AFTER INSERT ON customers
  FOR EACH ROW
  EXECUTE FUNCTION notify_new_customer();

NOTIFY speichert für einen Listener ohne aktive Verbindung kein Protokoll zur erneuten Verarbeitung. Benachrichtigungen während einer unterbrochenen Verbindung gehen verloren und werden beim erneuten Verbinden nicht nachgeholt. Die 2026 geprüfte Dokumentation von PostgreSQL setzt das standardmäßige Nutzdatenlimit auf weniger als 8000 Byte. Deshalb sollte nur eine ID gesendet und die vollständige Zeile vom Agenten abgerufen werden. Zustellverhalten und Nutzdatenlimits von PostgreSQL NOTIFY. LISTEN/NOTIFY eignet sich für nahezu unmittelbare Reaktionen auf Datenänderungen, wenn ein gelegentlicher Verlust beim Neuverbinden akzeptabel ist. Muss jede Änderung verarbeitet werden, passen Kafka oder SQS besser. Eine Datenbank in einem privaten Netzwerk lässt sich über Bridge verbinden, ohne sie öffentlich erreichbar zu machen. Private Infrastruktur über Bridge erreichen. Postgres LISTEN/NOTIFY einrichten.

AWS SQS: dauerhafte Queue mit Polling

Eine SQS-Verbindung fragt eine Queue per Long Polling ab und startet pro Nachricht eine Ausführung für jeden verknüpften Agenten. Nachrichten bleiben erhalten, bis alle verknüpften Ausführungen abgeschlossen sind und die Verbindung sie löscht. Neustarts von Workern und Lastspitzen führen dadurch nicht zum Verlust gepufferter Arbeit. Schlägt eine Ausführung fehl, erscheint die Nachricht nach ihrem Visibility Timeout erneut und wird wiederholt. Wiederholt fehlgeschlagene Nachrichten lassen sich an eine in AWS konfigurierte Dead-Letter-Queue weiterleiten. Standard-Queues garantieren keine Reihenfolge; FIFO-Queues bewahren sie innerhalb einer Nachrichtengruppe.

Dieses Muster eignet sich für zuverlässige asynchrone Arbeit, die Fehler überstehen muss, für die keine eigene Wiederholungslogik entwickelt werden soll. Laut der 2026 geprüften AWS-Dokumentation kann ein Long Poll bei einer leeren Queue bis zu 20 Sekunden warten; trifft eine Nachricht ein, kehrt die Anfrage früher zurück. AWS-SQS-Limits für Long Polling. Zusätzlich sind ein AWS-Konto und Zugangsdaten erforderlich. SQS Queue und Polling konfigurieren.

Direkter Vergleich

Zustellung, Reihenfolge, erneute Verarbeitung, Rückstaukontrolle und Latenz unterscheiden diese Auslöser:

Das richtige Muster auswählen