Netzwerke machen die Ergebnisse ungewiss
Eine Anfrage kann den Server erreichen und erfolgreich festgeschrieben werden, selbst wenn der Browser nie die Antwort erhält. Ein erneuter Versuch ist sinnvoll, aber ohne eine stabile Anforderungsidentität kann der Server einen erneuten Versuch nicht von einem neuen Befehl unterscheiden.
Bei der Erstellung öffentlicher Links kann diese Mehrdeutigkeit zu doppelten Aliasen, verwirrenden Datensätzen oder wiederholten Nebenwirkungen führen.
Ein Schlüssel repräsentiert eine beabsichtigte Mutation
Der Client sendet mit der Erstellungsanforderung einen eindeutigen Idempotenzschlüssel. Der Server speichert das Ergebnis zusammen mit einem Fingerabdruck der Eingabe. Durch Wiederholen derselben Taste und Eingabe wird das ursprüngliche Ergebnis zurückgegeben.
Die Verwendung derselben Taste mit unterschiedlichen Eingaben wird als Konflikt abgelehnt. Dies schützt sowohl den Client als auch den Server davor, versehentlich die Bedeutung eines vorherigen Befehls zu ändern.
Bei der Produktion kommt es auf die Haltbarkeit an
Ein In-Memory-Idempotenzspeicher reicht für isolierte Tests aus, nicht für einen Produktionsdienst mit mehreren Instanzen. Der Produktionsschlüssel und das Ergebnis müssen sich in derselben dauerhaften Domänengrenze wie die Mutation befinden, mit Ablauf und Mandantenbereich.
Das gleiche Muster gilt für Zahlungen, Webhook-Verarbeitung, Importe und Jobs, bei denen ein Duplikateffekt kostspielig wäre.