WebhookIO
Technisch

Kritische Maßnahmen zur Vermeidung von Webhook-Anfragenverlusten

WebhookIO Team •
#webhook#zuverlässigkeit#devops#best-practices
Webhook Zuverlässigkeit - Datensicherheit

Webhooks sind großartig, bis Ihr Zielserver abstürzt oder die Netzwerkverbindung unterbrochen wird. Webhooks arbeiten naturgemäß nach dem “Fire and Forget”-Prinzip, aber in kritischen Geschäftsprozessen (wie dem Empfang von Zahlungen) ist “Vergessen” keine Option.

In diesem Artikel werden wir untersuchen, wie Sie Ihre Webhook-Architektur widerstandsfähiger (resilient) machen und Datenverlust auf 0% reduzieren können.

1. Timeout-Management

Der Dienst, der den Webhook sendet, wartet nicht ewig auf eine Antwort. Es gibt normalerweise eine Timeout-Zeit von 5-10 Sekunden. Wenn Ihr Endpoint nicht innerhalb dieser Zeit antwortet, gilt die Anfrage als fehlgeschlagen.

Lösung: Führen Sie niemals lang andauernde Operationen (Erstellung von PDFs, Senden von E-Mails, Datenbank-Reporting) auf dem Endpoint durch, der den Webhook empfängt. Das Einzige, was Sie tun müssen, ist:

  1. Empfangen Sie die Anfrage.
  2. Legen Sie sie in die Warteschlange (Queue).
  3. Senden Sie 200 OK an den Absender zurück.
  4. Führen Sie die Operation im Hintergrund (Background Worker) durch.

2. Retry-Mechanismus (Wiederholung)

Jedes System kann abstürzen. Ihr Server könnte gewartet werden oder es könnte ein sofortiger Netzwerkfehler auftreten. In diesen Fällen darf der Webhook nicht verloren gehen.

Exponential Backoff: Anstatt eine fehlgeschlagene Anfrage sofort erneut zu versuchen, ist die gesündeste Methode, es durch Erhöhen der Wartezeit zu versuchen.

Überprüfen Sie unbedingt die Retry-Richtlinie Ihres Webhook-Anbieters (z. B. Stripe). Richten Sie auch unbedingt eine Retry-Strategie in Ihren eigenen Webhook-Einreichungen ein.

3. Idempotenz

Der Retry-Mechanismus ist großartig, hat aber eine gefährliche Nebenwirkung: Dieselbe Anfrage kommt mehr als einmal an. Wenn die 200 OK-Antwort aufgrund eines Netzwerkfehlers den Absender nicht erreicht, sendet der Absender denselben Webhook erneut. Wenn Ihr Code nicht darauf vorbereitet ist, könnten Sie dem Kunden den Betrag zweimal berechnen oder doppelte Datensätze in der Datenbank erstellen.

Lösung: In jeder Webhook-Anfrage befindet sich eine eindeutige ID (Event ID). Bewahren Sie diese ID in Ihrer Datenbank oder Redis auf.

if redis.exists(event_id) {
    return 200 OK; // Bereits verarbeitet, nicht erneut tun.
}
process_payment();
redis.save(event_id);

4. Sicherheit und Verifizierung (HMAC)

Da Ihr Endpoint öffentlich ist, können böswillige Personen gefälschte Webhook-Anfragen senden. Um dies zu verhindern, ist es zwingend erforderlich, die HMAC (Hash-based Message Authentication Code)-Signatur zu verifizieren. Der Absender hasht die Payload mit einem geheimen Schlüssel und sendet sie im Header. Sie führen denselben Vorgang durch und prüfen, ob sie übereinstimmt.

5. Dead Letter Queue (DLQ)

Was passiert, wenn alle Wiederholungsversuche fehlschlagen? Anstatt die Daten zu löschen, verschieben Sie sie in einen separaten Bereich namens “Dead Letter Queue”. Sie können die fehlerhaften Datensätze hier später manuell untersuchen und nach Behebung des Problems erneut verarbeiten.

Zusammenfassung

Der Aufbau einer zuverlässigen Webhook-Architektur erfordert Warteschlangenmanagement, Retry-Strategien und Sicherheitsmaßnahmen.

Wenn Sie nicht die gesamte Infrastruktur (Queue, Retry, DLQ, Logging) von Grund auf neu aufbauen möchten, können Sie ein Webhook Gateway wie WebhookIO verwenden. WebhookIO empfängt alle eingehenden Anfragen für Sie, stellt sie in die Warteschlange und liefert sie sicher an Sie aus, wenn Ihr Endpoint bereit ist.

← Back to Blog