Wie würdest du sicherstellen, dass ein Payment-Webhook einen Kunden nie doppelt belastet oder doppelt freischaltet?

Behandle die Zustellung als mindestens einmal und mach den Handler idempotent. Prüf zuerst die Signatur, speicher dann die Event-Id des Anbieters hinter einem Unique Constraint und gib sofort 200 zurück, wenn du sie schon gesehen hast. Führ die Zustandsänderung und das Einfügen der Id in einer Transaktion aus, damit ein Absturz sie nicht halb anwendet. Halt den Handler schnell, indem du langsame Arbeit in eine Queue schiebst, und lass den Anbieter erneut zustellen, wenn du wirklich scheiterst.

Meine Grundannahme ist, dass der Anbieter dasselbe Event mehr als einmal, in falscher Reihenfolge und manchmal Stunden später zustellt, weil alle drei vorkommen. Der Handler prüft also zuerst Signatur und Zeitstempel und fügt dann die Event-Id des Anbieters in eine processed_events-Tabelle mit einem Unique Index ein. Kollidiert dieses Insert, haben wir es schon behandelt, und ich gebe sofort 200 zurück, statt die Arbeit erneut zu machen. Das wichtige Detail ist, dass das Insert und die eigentliche Wirkung, das Freischalten des Abos oder das Verbuchen der Zahlung, in derselben Transaktion passieren, damit ein auf halbem Weg sterbender Prozess nicht eines ohne das andere hinterlässt. Alles Langsame, etwa eine Belegmail, geht mit eigenem Idempotenzschlüssel in eine Queue. Ich speichere außerdem den Event-Zeitstempel und ignoriere ein Event, das älter ist als der Zustand, den ich schon habe, und genau das rettet dich, wenn eine Kündigung vor dem Upgrade eintrifft, das ihr vorausging. Bei Fehlern gebe ich bewusst 500 zurück, damit der Anbieter erneut zustellt, und ich alarmiere, wenn ein Event in der Dead-Letter-Queue landet.