Wie machst du einen Schreib-Endpoint sicher wiederholbar?

Gib dem Client einen Idempotency Key, speicher ihn zusammen mit dem Ergebnis des ersten erfolgreichen Schreibvorgangs und gib bei jeder Wiederholung dieses gespeicherte Ergebnis zurück. Erzwing Eindeutigkeit auf Datenbankebene, damit gleichzeitige Duplikate kollidieren statt doppelt zu schreiben. Scope die Keys pro Kunde, lass sie nach einem sinnvollen Zeitraum verfallen und nimm den natürlichen Business-Key wie eine Bestell-ID als Dedup-Anker, wann immer es einen gibt.

Der Client erzeugt einen Idempotency Key, meist eine UUID, und schickt ihn als Header. Serverseitig halte ich eine Tabelle mit Kunden-ID plus diesem Key als Unique Constraint, und ich schreibe Key und Antwort in derselben Transaktion wie den fachlichen Schreibvorgang. Eine Wiederholung läuft dann in den Unique Constraint oder findet die gespeicherte Zeile und spielt einfach die ursprüngliche Antwort ab, Retries sind also gratis. Zwei Details zählen. Erstens muss die Eindeutigkeit in der Datenbank leben, denn wenn du erst ein select und dann ein insert machst, kommen zwei gleichzeitige Retries beide durch die Prüfung. Zweitens musst du entscheiden, was passiert, wenn der zweite Request eintrifft, während der erste noch läuft. Wir haben 409 mit einem Retry-After zurückgegeben statt zu blockieren, was unseren Connection Pool gesund gehalten hat. Ich speichere außerdem einen Hash des Request-Bodys, damit ein wiederverwendeter Key mit anderem Inhalt abgelehnt wird, statt still die falsche Antwort zu liefern.