Sie können die Webhook-Reihenfolge nicht garantieren

Dieser Artikel behandelt eines der Themen, zu denen wir die meisten Fragen erhalten: die Sicherstellung, dass Webhooks bestellt werden. Auf den ersten Blick scheint dies eine einfache Idee zu sein und leicht umzusetzen: Senden Sie einfach die Webhooks der Reihe nach.

Warum wollen die Leute eine garantierte Bestellung?

Bevor wir die Herausforderungen erklären, lassen Sie uns zuerst darüber sprechen, warum die Leute es überhaupt wollen.

Stellen Sie sich beispielsweise ein einfaches Abrechnungssystem vor, bei dem Sie zwei Arten von Entitäten haben, einen Kunden und eine Karte. Ein Kunde verfügt über Informationen über die Person, die die Zahlung vornimmt, wie z. B. ihre Privatadresse und Telefonnummer. Eine Karte enthält Informationen über das verwendete Zahlungsmittel (z. B. Kreditkarte) und einen Verweis auf den zugehörigen Kunden.

Stellen Sie sich nun vor, Sie haben ein Formular auf der Website, mit dem ein neuer Kunde gleichzeitig seine persönlichen Daten und seine Kartendaten hinzufügen kann. Dieses Formular auf der Rückseite erstellt beide und löst zwei Webhooks customer.created und card.created aus.

Wenn Sie die Reihenfolge nicht sicherstellen, erhält der Webhook-Endpunkt möglicherweise einen vor dem anderen. Es könnte also möglicherweise den Endpunkt-Webhook card.created empfangen, der auf den Client verweist, bevor der Endpunkt die Notiz erhält, dass der Client überhaupt erstellt wurde.

Was ist die offensichtliche Lösung für dieses Problem? Stellen Sie einfach die Lieferreihenfolge sicher!

Garantieauftrag, wenn Webhooks fehlschlagen

Die erste Herausforderung bei der Bestellung ergibt sich aus der Berücksichtigung von Lieferausfällen. Was soll passieren, wenn die Zustellung fehlschlägt? Sollen wir die gesamte Nachrichtenwarteschlange blockieren? Oder sollen wir die Bestellung nur dann garantieren, wenn alles funktioniert und keine Fehler vorliegen?

Wenn wir die gesamte Warteschlange blockieren, würde ein einziger Fehler beim Senden eines untergeordneten Webhooks der Bereitstellung des Webhooks und damit dem gesamten Dienst völlig misstrauen. Denken Sie darüber nach, sie erhalten keine Nachrichten aufgrund eines Fehlers bei der Übermittlung einer Art von Nachrichten. Das ist offensichtlich nicht gut.

Die Alternative besteht dann darin, die Bestellung nur dann zu garantieren, wenn keine Fehler vorliegen. Es ist ganz einfach, aber das Problem ist, dass wir die Reihenfolge nicht wirklich sicherstellen. Wenn Ihre Kunden im Pannenfall eine Out-of-Stock-Lieferung sicherstellen müssen, können sie sich genauso gut mit Out-of-Stock-Lieferungen im Allgemeinen befassen. Es ist der gleiche Code. Stellen Sie also in diesem Fall sicher, dass der Befehl keinen Wert hinzufügt.

Garantiebestellung funktioniert nicht wirklich

Die andere, größere Herausforderung bei der Sicherstellung der Reihenfolge von Webhooks besteht darin, dass selbst wenn Sie Webhooks in der richtigen Reihenfolge senden, diese möglicherweise nicht in der richtigen Reihenfolge verarbeitet werden.

Nehmen Sie beispielsweise an, wir haben zwei Ereignisse: das erste und das zweite, und Sie senden das erste als erstes und das zweite als zweites. Angenommen, der Dienst, der Webhooks verwendet, sieht in etwa so aus wie dieser Pseudo-Python-Code:

def handler_for_event_first(payload): # Dies wird kein Schlaf sein, sondern ein weiterer langsamer Aufruf (db, externe API) schlafen(1) do_stuff(Nutzlast) gibt HTTP_OK_200 zurück def handler_for_event_second(Nutzlast): do_stuff(Nutzlast) gibt HTTP_OK_200 zurück

Daher gibt es zwei Handler, einen für den ersten, der sehr langsam ist, und einen für den zweiten, der ziemlich schnell ist. Hinweis: Wir haben die sleep-Direktive verwendet, um Langsamkeit zu emulieren, in Wirklichkeit wird es ein weiterer langsamer Anruf sein.

Wenn Sie sich diesen Code ansehen, bedeutet dies, dass selbst wenn Sie den ersten Code zuerst senden, er in der Praxis nach dem zweiten verarbeitet wird und nicht vorher. Dies liegt daran, dass die Funktion langsamer ist, obwohl der Handler zuerst aufgerufen wird, sodass ein großer Teil davon als zweites verarbeitet wird. In einem realistischeren Szenario wird sich dies wahrscheinlich eher als Race-Condition manifestieren, als dass die Reihenfolge nicht nur ausgefallen ist, sondern auch sehr undeterministisch.

Wir können dies leicht umgehen, indem wir nur einmal die erste abgeschlossene Verarbeitung senden (wir erhalten eine 200 für den Webhook-Handler), obwohl dies zwei zusätzliche Probleme mit sich bringt:

Wenn der Handler eine Sekunde braucht, um fertig zu werden (was nicht so selten vorkommt), ist unsere Webhook-Zustellung im Wesentlichen auf einen Webhook pro Sekunde beschränkt, was schrecklich ist, und es wird oft noch schlimmer sein. Die Best Practice bei der Aufnahme eingehender Webhooks besteht darin, eine grundlegende Validierung durchzuführen, den Webhook zur weiteren Verarbeitung in eine Warteschlange zu stellen und sofort eine erfolgreiche HTTP-Antwort zurückzugeben. Das bedeutet, dass das Warten auf das Ende des Ersten das Problem nicht löst, denn wenn die Warteschlange nicht der Reihe nach abgearbeitet wird (wiederum warten, bis der Erste fertig ist, bevor um ...