The Valley of Webhooks: Warum wir seit 15 Jahren ein Problem als Loesung wiederverwenden

Wer jemals Webhooks von Stripe, GitHub oder einem Identity-Provider in eine lokale Datenbank synchronisiert hat, kennt das Muster: Signatur-Verifikation, Dedup-Tabelle, Buffer für out-of-order-Events, Bootstrap-Importer, und irgendwann ein 3-Uhr-nachts-Cron-Job, der die eigenen Tabellen gegen die Provider-API abgleicht. Der Autor von “The Valley of Webhooks” hat dieses System dreimal gebaut – und argumentiert, dass Webhooks für Datenreplikation ein lokales Optimum sind, das wir seit 2007 nicht verlassen haben.

Das Kernproblem: Webhooks sind Benachrichtigungen, keine Daten. Ein Provider hat intern einen geordneten Log, zerstückelt ihn in einzelne HTTP-POSTs, schickt sie unzuverlässig und ungeordnet an deinen Endpoint – und du baust den Log auf deiner Seite wieder zusammen. Das Ergebnis ist ein ganzer Tooling-Stack aus Dedup-Stores, Dead-Letter-Queues, Replay-Dashboards und Reconciliation-Crons, der die Lücken füllt, die das primitive von vornherein aufreißt. Svix, Hookdeck, EventBridge – alle lösen Symptome, nicht die Ursache.

Der Essay schlägt einen Richtungswechsel vor: Statt Push die Richtung umdrehen – der Consumer liest einen geordneten, cursor-basierten Change-Log vom Provider. Bootstrap ist dann nur ein Read ohne Cursor, Resumability ist der Cursor selbst, und ein Checksum am Ende des Logs ermöglicht Verifikation. Der Autor hat dazu das Protokoll SCROLL spezifiziert. Ein klarer, gut geschriebener Essay, der jeden trifft, der schon mal eine Webhook-Integration debuggt hat.