Ein Idempotency-Key lässt einen wiederholten Schreibvorgang genau einmal landen

Die zwei Spalten unterscheiden sich um ein Ereignis, und das kontrolliert niemand. Zwischen Ihrer Anfrage und ihrer Antwort sitzt ein Netz, und ein Netz bricht gelegentlich eine laufende Verbindung ab. Teuer wird das hier durch die Reihenfolge: Bis die Antwort verloren geht, hat das Zielsystem den Vorschlag längst gebucht. In der Zeichnung ist dieses System Lexware Office, und dieselbe Abfolge gilt, wo der Schreibvorgang auch landet. Ihre Seite hält einen Timeout und kein Ergebnis, und das ist der eine Zustand, in dem ein Schreibvorgang Sie nie zurücklassen sollte.

Ohne Key gibt es zwei Auswege, und beide kosten etwas. Sie können fragen, was geschah, und das heißt eine Supportanfrage und Warten. Oder Sie senden die Anfrage erneut, was ein richtiges Ergebnis liefert, wenn der Versuch scheiterte, und eine Dublette, wenn er gelang. Erneut zu senden tut Retry-Logik von sich aus, denn eine Wiederholung reagiert auf eine fehlende Antwort, und eine fehlende Antwort ist kein Beleg für einen fehlenden Schreibvorgang.

Die Abgrenzung macht einen selbst gewählten Key tragfähig. Ein Key wird nicht als globaler Wert gelesen, er gehört zu einem Mandanten, einem Nutzer und dem einen Vorgang, mit dem er gesendet wurde, zwei Ihrer Kunden können also am selben Morgen invoice-1 wählen und sich nie begegnen. Deshalb entwerfen Sie den Key und wir geben nie einen aus: Er muss nur innerhalb Ihrer eigenen Vorgänge eindeutig sein.

Geprüft wird nicht nur der Name, sondern auch die Anfrage selbst. Kommt derselbe Key mit anderen Daten dahinter an, ist das keine Wiederholung, sondern ein neuer Vorgang im alten Namen, und er wird mit einer 422 beantwortet. Auf der Kombination ruht die Zusage: Der Key sagt, welcher Vorgang das ist, und die Anfrage sagt, ob es noch derselbe ist.

Das ist der Fall, in den ein ungeduldiger Aufrufer läuft, und es lohnt sich, ihn zu kennen, bevor Sie darum herum bauen. Ein eingereihter Schreibvorgang nach DATEV Unternehmen Online kann dauern, also sendet jemand, der auf einen Ladekreis schaut, die Anfrage erneut. Mit einem Key gibt diese Wiederholung dieselbe Task-ID zurück, statt einen weiteren Schreibvorgang einzureihen, und die Task-ID ist das, was Sie ohnehin abgefragt haben. Die Taktung hinter der Warteschlange gehört zu Asynchronous Processing, der Schreibvorgang bleibt also innerhalb der Limits jedes Systems, während Sie warten.

Ein Fehlschlag wird hier anders behandelt als ein Erfolg, und das mit Absicht. Scheitert der eingereihte Vorgang, wird der Key freigegeben, der naheliegende nächste Schritt funktioniert also: Daten korrigieren und unter demselben Key erneut senden, ohne einen neuen zu erfinden für etwas, das Sie weiterhin als einen Vorgang begreifen. Gelang er, bleibt der Key an diese Antwort gebunden, denn ihn wiederzuverwenden hieße, um die Dublette zu bitten, die er verhindern soll.

Eine doppelte Buchung ist auf eine Weise teuer, die schlecht skaliert. Sie fällt spät auf, meist dem Buchhalter des Kunden und nicht Ihrem Monitoring, sie muss im Zielsystem von Hand storniert werden, und das Gespräch darüber landet bei dem, der am nächsten steht. Volumen macht es schlimmer: Eine Reisemanagement-Plattform, die Lieferantenrechnungen für Hunderte Gesellschaften nach DATEV schiebt, und genau das tut Lanes & Planes, kann unmöglich jeden Schreibvorgang von Hand prüfen.

Den Vorgang zu benennen verschiebt diese ganze Problemklasse in den Moment, in dem die Anfrage gestellt wird, und das ist der einzige Moment, in dem jemand genug Kontext hat, um damit umzugehen. Die Wiederholung wird zu etwas Sicherem, und die Arbeit, die sie spart, ist die Art, die Produkt- und Entwicklungsteams sonst jahrelang pflegen würden, eine Zustandstabelle und einen Abgleichlauf nach dem anderen.