Idempotenz in verteilten Systemen, die tatsächlich funktioniert
Vermeiden Sie doppelte Nebeneffekte
Idempotenz in verteilten Systemen ist die Eigenschaft, die Sie rettet, wenn das Netzwerk versagt, die Warteschlange erneut versucht, der Client in Panik gerät und der Administrator die Wiedergabe auslöst. In Produktionsystemen ist die doppelte Zustellung normal. Doppelte Nebenwirkungen sind der Fehler.
HTTP definiert eine idempotente Methode als eine, bei der mehrere identische Anfragen die gleiche beabsichtigte Auswirkung auf den Server haben wie eine einzelne Anfrage. Aus diesem Grund sind PUT, DELETE und sichere Methoden in den Protokollsemantiken idempotent und können nach einer Kommunikationsstörung automatisch wiederholt werden.
Diese Definition ist nützlich, reicht aber nicht aus. In realen Architekturen ist Idempotenz keine Trivia-Antwort im HTTP-Protokoll. Sie ist eine Geschäftsgarantie. Wenn ein Kunde einmal auf „Bezahlen" drückt, dürfen Sie ihn nicht zweimal belasten, nur weil zwischen dem Commit und der Antwort ein Timeout aufgetreten ist. Wenn ein Worker den Bestand aktualisiert und vor der Bestätigung der Nachricht abstürzt, dürfen Sie den Lagerbestand nicht zweimal reduzieren, nur weil der Broker die Nachricht erneut zugestellt hat. Das ist der Maßstab.
Der Fehler, den ich immer wieder sehe, ist die Behandlung von Idempotenz als Transporteigenschaft statt als Systemeigenschaft. Entduplizierung in Warteschlangen, HTTP-Verben und Client-Wiederholungsversuche helfen, aber keines davon rettet ein Design, bei dem dieselbe Geschäftsaussicht eine zweite Nebenwirkung erzeugt. Wenn Sie den breiteren Rahmen dafür kennen wollen, wie diese Integrationsentscheidungen in Servicegrenzen und Persistenz-Trade-offs passen, beginnen Sie mit App-Architektur in der Produktion: Integrationsmuster, Code-Design und Datenzugriff.
Woher Duplikate in der Produktion kommen
Duplikate entstehen nicht, weil Teams sorglos sind. Sie entstehen, weil verteilte Systeme wiederholen, neu anordnen und wiedergeben.
Ein Client kann eine Erstanfrage senden, der Server kann sie commiten, und die Antwort kann trotzdem auf der Leitung verschwinden. Genau deshalb unterscheidet HTTP idempotente Methoden und deshalb bieten Zahlungs-APIs wie Stripe und PayPal für unsichere Methoden wie POST explizite Idempotenzmechanismen an.
Nachrichtenbroker machen das Problem noch offensichtlicher. Zustellung mindestens einmal bedeutet, dass ein Verbraucher für dieselbe Nachricht wiederholt aufgerufen werden kann, und ein Handler kann die Datenbank erfolgreich aktualisieren, aber vor der Bestätigung fehlschlagen, was dazu führt, dass der Broker dieselbe Nachricht erneut zustellt.
Webhooks sind nicht anders. GitHub sagt, dass Webhook-Zustellungen in falscher Reihenfolge eintreffen können, fehlgeschlagene Zustellungen nicht automatisch erneut zugestellt werden und jede Zustellung eine eindeutige GUID X-GitHub-Delivery enthält, die Sie beim Schutz vor Wiedergabe verwenden sollten. Für eine praktische Architekturansicht von Chat-Endpunkten als Interaktionsgrenzen siehe Chat-Plattformen als Systemschnittstellen in modernen Systemen.
Selbst Systeme, die stärkere Garantien werben, lassen Ihnen noch Arbeit übrig. Kafka kann doppelte Einträge in Kafka-Logs mit idempotenten Produzenten verhindern und kann genau-einmal-Zustellung für Read-Process-Write-Flows bieten, die innerhalb von Kafka mit Transaktionen und read_committed-Verbleibern bleiben. Aber Kafkas eigene Design-Dokumente sind klar, dass externe Systeme immer noch Koordination mit Offsets und Ausgaben erfordern. Die genau-einmal-Zustellung von Google Cloud Pub/Sub ist auf Pull-Abonnements begrenzt, innerhalb einer Cloud-Region und erfordert immer noch, dass Clients den Verarbeitungsfortschritt verfolgen, bis die Bestätigung erfolgreich ist.
Meine Meinungsäußerung ist einfach. Gehen Sie davon aus, dass der Transport wiederholt wird. Gehen Sie davon aus, dass Administratoren die Wiedergabe auslösen. Gehen Sie davon aus, dass Webhooks verspätet eintreffen. Gestalten Sie den Schreibpfad so, dass eine wiederholte Absicht keine zweite Geschäftswirkung erzeugen kann. Fehlerdesign ist eng damit verwandt: Wie Fehler eingewickelt, übersetzt und als wiederholbar versus nicht wiederholbar klassifiziert werden, ist Teil derselben Grenzdisziplin – Go Fehlerbehandlungsarchitektur: Grenzen und Muster deckt die Klassifizierung wiederholbarer Fehler, Grenzübersetzung und die Sentinel-Muster ab, die Wiederholungslogik ermöglichen, fundierte Entscheidungen zu treffen. Wenn Wiederholungsversuche weiterhin eine kranke Abhängigkeit treffen, ein Schalter an der Integrationsgrenze schlägt schnell fehl, bevor Wiederholungsstürme doppelte Arbeit verstärken.
Der API-Vertrag, dem ich wirklich vertraue
Wie verhindern Idempotenzschlüssel doppelte API-Anfragen
Der einzige API-Vertrag, dem ich bei mutierenden Operationen vertraue, ist vom Aufrufer bereitgestellte Absicht plus serverseitige Persistenz.
AWS empfiehlt eine vom Aufrufer bereitgestellte Anfragekennung und warnt davor, dass der Dienst den Idempotenz-Token gemeinsam mit der mutierenden Arbeit atomar aufzeichnen muss. Stripe speichert den ersten Statuscode und Antwortkörper für einen Schlüssel, vergleicht spätere Parameter mit der ursprünglichen Anfrage und gibt dasselbe Ergebnis für Wiederholungsversuche zurück. PayPal verwendet PayPal-Request-Id auf unterstützten POST-APIs und gibt den neuesten Status für die vorherige Anfrage mit diesemselben Header zurück.
Das führt zu einem praktischen Vertrag:
- Der Client generiert einen Idempotenzschlüssel für eine Geschäftsoperation.
- Der Server schränkt diesen Schlüssel nach Mieter und Operationsname ein.
- Der Server speichert einen Anfrage-Hash, sodass derselbe Schlüssel nicht für eine andere Payload wiederverwendet werden kann.
- Der Server zeichnet Zustände wie
pending,completedoderfailedauf. - Wiederholungsversuche mit demselben Schlüssel geben entweder das gespeicherte Ergebnis zurück oder einen stabilen Zeiger darauf.
- Wiederholungsversuche mit demselben Schlüssel und einer anderen Payload schlagen deutlich fehl.
Es gibt einen IETF-Entwurf für den Header Idempotency-Key, aber Stand 09.05.2026 ist er im IETF Datatracker immer noch als abgelaufener Internet-Entwurf aufgeführt, nicht als veröffentlichte RFC. In der Praxis ist der Headername weiterhin weit verbreitet nützlich als de-facto-Konvention, aber Sie sollten den Vertrag in Ihrer eigenen API dokumentieren, anstatt zu tun, als wäre der Standard abgeschlossen.
Was sollte der Schlüssel repräsentieren? Absicht. Nicht einen HTTP-Versuch. Nicht eine TCP-Verbindung. Nicht einen Wiederholungszaehler. Wenn der Benutzer „Bestellung 123 einmal erstellen" meint, muss jeder Wiederholungsversuch für diesen selben Befehl denselben Schlüssel wiederverwenden. Wenn der Benutzer „eine zweite Bestellung aufgeben" meint, muss das einen anderen Schlüssel verwenden.
Eine Anfrage-ID ist zum Tracing. Ein Idempotenzschlüssel ist für Korrektheit. Wenn Sie diese verwechseln, sehen Ihre Dashboards ordentlich aus, während Ihr Geld doppelt bewegt wird.
Warum PUT nicht ausreicht
Nein, HTTP PUT reicht nicht aus, um eine Operation idempotent zu machen.
Ja, RFC 9110 gibt PUT idempotente Semantiken. Aber wenn Ihr PUT-Handler ein neues Downstream-Ereignis auslöst, bei jedem Wiederholungsversuch eine E-Mail sendet oder einen externen Anbieter erneut belastet, dann hat Ihre Implementierung den Geschäftsvertrag verletzt, auch wenn Ihr Routenname respektabel aussieht.
Die Wahl des Verbs hilft Clients, die Absicht zu verstehen. Es implementiert die Absicht nicht für Sie.
Verwenden Sie PUT, wenn das Ressourcenmodell wirklich eine vollständige Ersetzung oder Upsert-Style-Operation passt. Verwenden Sie POST, wenn Sie Befehle oder Aktionen erstellen. Aber für jede Mutation, die über Netzwerkgrenzen hinweg wiederholt werden könnte, dokumentieren Sie einen expliziten Idempotenzvertrag. Wenn Ihre mutierenden Aktionen aus Chat-Workflows ausgelöst werden, gilt derselbe Vertrag in Slack-Integrationsmuster für Alarme und Workflows und Discord-Integrationsmuster für Alarme und Steuerkreise. Versteckte Nebenwirkungen sind der Ort, an dem Architektur stirbt.
Wie lange sollte ein Idempotenzschlüssel gespeichert werden
Länger als Ihr Transportteam möchte.
Stripe sagt, dass Schlüssel nach mindestens 24 Stunden gelöscht werden können. PayPal sagt, dass die Aufbewahrung API-spezifisch ist und Beispiele gibt, die bis zu 45 Tage dauern können. Amazon SQS FIFO entdupliziert nur innerhalb eines 5-Minuten-Fensters. GitHub behält letzte Zustellungen für 3 Tage bei für manuelle Neuzustellung. Diese Zahlen sind wild unterschiedlich, weil die richtige Aufbewahrungsperiode eine Geschäftsentscheidung ist, kein Protokoll-Standardwert.
Wenn Sie Schlüssel nur für fünf Minuten behalten, weil Ihre Warteschlange das tut, gestalten Sie keine Idempotenz. Sie kopieren eine Transportbegrenzung in Ihre Geschäftsschicht.
Behalten Sie Idempotenz-Aufzeichnungen für mindestens das Maximum dieser Fenster:
- Client-Wiederholungszeitraum
- Warteschlangen-Redrive-Zeitraum
- Webhook-Wiedergabe-Zeitraum
- Administrator-Wiedergabe-Zeitraum
- Abrechnungs- oder Kompensationszeitraum für geldbewegende Operationen
Für Zahlungen, Buchungen und Provision bedeutet das oft Stunden oder Tage, nicht Minuten.
AWS weist auch auf zwei Anti-Pattern hin, denen ich voll zustimme. Verwenden Sie keine Zeitstempel als Schlüssel, weil Uhrverschiebung und Kollisionen sie unzuverlässig machen. Speichern Sie nicht blind gesamte Anfrage-Payloads als Entdup-Aufzeichnung für jede Anfrage, weil das Leistung und Skalierbarkeit schadet. Speichern Sie einen normalisierten Anfrage-Hash plus den minimalen Antwortzustand, den Sie benötigen, um sicher zu wiederholen. Wenn Sie den ersten Antwortbyte für Byte reproduzieren müssen, speichern Sie den kanonischen Antwortkörper, wie es Stripe tut.
Die Datenbankmuster, die Idempotenz real machen
Idempotenz wird real, wenn die Persistenzschicht ein Rennen genau einmal gewinnen kann.
PostgreSQL gibt Ihnen hier zwei kritische Primitive. Eindeutige Constraints erzwingen Eindeutigkeit auf einer oder mehreren Spalten, und INSERT ... ON CONFLICT lässt Sie eine alternative Aktion definieren, anstatt bei einer Eindeutigkeitswidrigkeit zu fehlschlagen. PostgreSQL dokumentiert auch, dass ON CONFLICT DO UPDATE ein atomares Insert-or-Update-Ergebnis unter Konkurrenz garantiert.
Das bedeutet, dass Ihre Idempotenzschicht normalerweise mit einer Tabelle wie dieser beginnen sollte:
create table api_idempotency (
tenant_id text not null,
operation text not null,
idempotency_key text not null,
request_hash text not null,
state text not null,
status_code integer,
response_body jsonb,
resource_type text,
resource_id text,
created_at timestamptz not null default now(),
expires_at timestamptz not null,
primary key (tenant_id, operation, idempotency_key)
);
Und der Handhabungsfluss sollte so aussehen:
begin transaction
try insert (tenant_id, operation, idempotency_key, request_hash, state='pending')
on conflict do nothing
load row for (tenant_id, operation, idempotency_key) for update
if row.request_hash != incoming_request_hash
fail with conflict or validation error
if row.state = 'completed'
return stored response
if row.state = 'pending' and row was created by another live request
either wait briefly, or fail fast with a retryable response
perform local business mutation
store stable result in idempotency row
set state = 'completed'
commit
return result
Der wichtige Teil ist nicht die Syntax. Der wichtige Teil ist die Atomizität. Das Aufzeichnen des Schlüssels und das Ausführen der Mutation müssen zusammen erfolgreich sein oder zusammen fehlschlagen. AWS sagt dies explizit für API-Idempotenz, und dieselbe Regel gilt in SQL-gestützten Diensten.
Führen Sie keine naive Check-then-Act-Folge wie „select key; if missing then insert order" aus. Unter Konkurrenz können zwei Anfragen den Check bestehen und beide die Nebenwirkung erzeugen. Ein eindeutiger Constraint ist nicht optional. Er ist der Mechanismus, der Ihre Architektur von optimistischer Folklore in etwas verwandelt, das Sie unter Last beweisen können.
Hier ist die Regel, die ich in Reviews verwende. Wenn die Entdup-Entscheidung nicht durch dieselbe transaktionale Grenze geschützt ist wie die Mutation, haben Sie keine Idempotenz. Sie haben Hoffnung.
Nachrichten, Ereignisse und Webhooks brauchen ihre eigene Grenze
Wie verarbeiten Verbraucher doppelte Ereignisse und Nachrichten
Für Nachrichtenverbraucher ist das klassische Muster immer noch das richtige. Speichern Sie verarbeitete Nachrichten-IDs in derselben Datenbanktransaktion wie die Geschäftsaktualisierung. Chris Richardson beschreibt den PROCESSED_MESSAGES-Tabellenansatz direkt, indem er einen Primärschlüssel auf Abonnent und Nachrichten-ID verwendet, sodass Duplikate sauber fehlschlagen und ignoriert werden können.
Viele Teams nennen diesen expliziten processed_messages-Speicher eine Inbox-Tabelle. Die Bezeichnung ist weniger wichtig als die Regel. Der Empfänger muss den Beweis speichern, dass er die Nachricht bereits verarbeitet hat, bevor ein Wiederholungsversuch sicher nichts tun kann.
Eine minimale Form sieht so aus:
create table processed_messages (
subscriber_id text not null,
message_id text not null,
processed_at timestamptz not null default now(),
primary key (subscriber_id, message_id)
);
Und der Verbraucherfluss ist genauso streng wie der HTTP-Flow:
begin transaction
insert into processed_messages (subscriber_id, message_id)
values (?, ?)
on conflict do nothing
if no row inserted
rollback
ack and ignore duplicate
apply business mutation
commit
ack message
Dieses Muster ist langweilig. Gut. Idempotenz sollte langweilig sein.
Es ist auch normalerweise besser, als sich auf Marketingbegriffe des Brokers zu verlassen. Kafkas genau-einmal-Unterstützung ist exzellent, wenn Sie innerhalb von Kafkas eigenem transaktionalem Modell bleiben, aber Kafkas Dokumente warnen immer noch, dass externe Ziele Kooperation benötigen. SQS FIFO reduziert doppelte Sendedaten nur innerhalb seines 5-Minuten-Entdup-Fensters. Pub/Sub genau-einmal erwartet immer noch, dass der Abonnent den Fortschritt verfolgt und doppelte Arbeit vermeidet, wenn Bestätigungen fehlschlagen.
Genau-einmal ist normalerweise eine lokale Optimierung. Idempotente Nebenwirkungen sind die Systemgarantie.
Kombinieren Sie Entdup mit dem Outbox-Muster
Wenn Ihr Dienst lokalen Zustand aktualisiert und auch ein Ereignis veröffentlicht, reicht idempotente Konsumption allein nicht aus. Sie brauchen auch einen sicheren Weg, das Ereignis nach dem Commit der lokalen Transaktion herauszubekommen.
Deshalb ist das transaktionale Outbox-Muster wichtig. Chris Richardson beschreibt die grundlegende Idee als Schreiben des Ereignisses in eine Outbox-Tabelle in derselben Transaktion wie die Geschäftsaktualisierung und dann asynchrones Veröffentlichen. Debezium sagt, das Outbox-Muster vermeidet Inkonsistenzen zwischen dem internen Zustand eines Dienstes und den von anderen Diensten verbrauchten Ereignissen. NServiceBus geht weiter und zeigt, wie Outbox-Verarbeitung eingehende Nachrichten entdupliziert und Zombie-Aufzeichnungen und Geister-Nachrichten vermeidet.
Das ist die Architektur, die ich für Dienste empfehle, die Daten besitzen und Integrationsereignisse veröffentlichen:
- Validieren und persistieren Sie den Befehl unter einem Idempotenzschlüssel.
- Schreiben Sie Geschäftszustand und Outbox-Ereignis in einer lokalen Transaktion.
- Lassen Sie CDC oder einen Outbox-Dispatcher das Ereignis veröffentlichen.
- Machen Sie auch Downstream-Verbraucher idempotent.
Outbox entfernt nicht die Notwendigkeit für idempotente Verbraucher. Es entfernt die Notwendigkeit, zu tun, als ob ein Datenbank-Commit und ein Broker-Veröffentlichen eine magische verteilte Transaktion sein können, wenn sie das normalerweise nicht können.
Webhooks sind nur Nachrichten mit besserem Branding
Behandeln Sie eingehende Webhooks genau wie Nachrichten von einer un vertrauenswürdigen Netzwerkkante.
GitHub dokumentiert, dass Zustellungen in falscher Reihenfolge eintreffen können, empfiehlt die Verwendung von X-Hub-Signature-256 zur Verifizierung der Authentizität und stellt X-GitHub-Delivery als eindeutige Zustellungs-ID bereit. Es bemerkt auch, dass Neuzustellungen dieselbe Zustellungs-ID wiederverwenden.
Also ist die Architektur straightforward:
- verifizieren Sie zuerst die Signatur
- verwenden Sie die Zustellungs-GUID als Entdup-Schlüssel
- persistieren Sie den Empfang vor Nebenwirkungen
- machen Sie Handler reihenfolgebewusst, anstatt Ankunftsreihenfolge anzunehmen
- queue Sie die schwere Arbeit und kehren Sie schnell zurück
Wenn Ihr Webhook-Handler direkt in Geschäftstabellen schreibt, bevor er den Empfang aufzeichnet, ist er nicht produktionsreif. Er macht nur schneller doppelte Fehler.
Sagas und Workflow-Engines brauchen immer noch Idempotenz
Sagas und dauerhafte Workflow-Engines löschen das Problem nicht. Sie machen es sichtbar.
Temporal empfiehlt, Aktivitäten idempotent zu schreiben, weil Aktivitäten nach Fehlern oder Timeouts wiederholt werden können. Seine Dokumente weisen sogar auf den Randfall hin, in dem ein Worker eine externe Nebenwirkung erfolgreich abschließt, aber vor dem Bericht der Fertigstellung abstürzt, was dazu führt, dass die Aktivität erneut ausgeführt wird. Temporal schlägt auch vor, eine Kombination aus Workflow-Lauf-ID und Aktivitäts-ID als stabilen Idempotenzschlüssel zu verwenden, wenn man Downstream-Dienste aufruft. Wenn Sie dies in der Service-Orchestrierung anwenden, deckt Go Microservices für AI/ML-Orchestrierung die breiteren Workflow-Trade-offs ab.
Das ist genau das richtige mentale Modell. Eine Workflow-Engine kann Ausführungsverlauf bewahren und Wiederholungsversuche koordinieren. Sie kann keine Karte rückwirkend entladen oder eine E-Mail ungesendet machen, es sei denn, Ihre Anwendung gibt ihr idempotente Schritte und idempotente Kompensationen.
Das Gleiche gilt für Sagas. Temporals eigene Saga-Anleitung beschreibt kompensierende Aktionen, die laufen, wenn ein Schritt fehlschlägt. Diese Kompensationen müssen auch idempotent sein. Wenn „Zahlung erstatten" zweimal läuft, haben Sie den ursprünglichen Fehler möglicherweise gelöst, indem Sie einen neuen erstellt haben.
Meine Regel hier ist brutal und einfach. Jede Aktivität, jeder Befehls-Handler, und jede Kompensation, die die Außenwelt berührt, sollte entweder natürlich idempotent sein oder einen echten Idempotenzschlüssel an das Downstream-System tragen.
Wie man Idempotenz vor der Produktion testet
Die meisten Teams testen glückliche Pfade und sind dann überrascht, wenn Wiederholungsversuche passieren. Das reicht nicht. Für Go-Teams deckt Testen von konkurrenzfähigem Go-Code mit testing/synctest wie man schnelle, deterministische Tests für Wiederholungsloops und Kontext-Deadline-Verhalten schreibt, ohne durch künstliche Verzögerungen zu schlafen.
Sie sollten automatisierte Tests für mindestens diese Fälle haben:
- der Server commitet die Mutation, aber die Antwort erreicht nie den Client
- zwei identische Anfragen wetteifern mit demselben Idempotenzschlüssel
- derselbe Schlüssel wird mit einer anderen Payload wiederverwendet
- ein Verbraucher commitet seine Datenbankarbeit und stürzt vor der Bestätigung ab
- ein Webhook wird mit derselben Zustellungs-ID wiedergegeben
- ein Outbox-Dispatcher veröffentlicht dasselbe Ereignis mehr als einmal
- eine Workflow-Aktivität schließt den externen Aufruf ab und stürzt vor dem Bericht der Fertigstellung ab
- eine Idempotenz-Aufzeichnung läuft ab und ein echter später Wiederholungsversuch trifft ein
AWS empfiehlt explizit umfassende Testsuiten, die erfolgreiche Anfragen, fehlgeschlagene Anfragen und doppelte Anfragen einschließen. Dieser Rat ist pedantisch und absolut korrekt.
Ich würde noch einen weiteren Fehlerbohrung hinzufügen. Verifizieren Sie, dass die wiedergegebene Antwort semantisch äquivalent zum ersten Ergebnis ist. AWS diskutiert spät ankommende Wiederholungsversuche und argumentiert für Antworten, die die ursprüngliche Bedeutung bewahren, auch nachdem sich der zugrunde liegende Zustand geändert hat. Das ist der Unterschied zwischen „keine zusätzliche Nebenwirkung geschah" und „der Aufrufer hat immer noch einen konsistenten Vertrag."
Meinungsstarre Regeln, die echte Systeme retten
Hier sind die Regeln, die ich in einer Architektur-Review durchsetzen würde.
Erstens, Idempotenzschlüssel gehören zur Geschäftsaussicht, nicht zu Transportversuchen.
Zweitens, schränken Sie jeden Schlüssel nach Mieter und Operation ein. Globale Schlüsselräume sind, wie unverbundene Anfragen kollidieren.
Drittens, persistieren Sie die Entdup-Entscheidung atomar mit der Mutation. Wenn das nicht wahr ist, ist das Design falsch.
Viertens, lehnen Sie gleich-Schlüssel-verschieden-Payload-Wiederholungsversuche ab. Stripe und AWS tun dies beide aus gutem Grund.
Fünftens, behalten Sie Schlüssel für den vollständigen Wiedergabe-Zeitraum des Geschäftsprozesses, nicht für das kürzeste Warteschlangenfenster.
Sechstens, koppeln Sie Produzenten mit einer Outbox und Verbraucher mit Nachrichten-ID-Tracking. Eine Seite ohne die andere ist ein halbes Design.
Siebtens, propagieren Sie dieselbe Operationsidentität downstream, wenn die Geschäftsaktion dieselbe ist. AWS empfiehlt explizit, den Idempotenz-Token entlang der Verarbeitungskette zu passieren.
Achtens, nehmen Sie niemals an, dass genau-einmal-Marketing die Notwendigkeit für idempotente Nebenwirkungen entfernt.
Wenn das streng klingt, gut. Idempotenz ist der Ort, an dem optimistische Architektur auf Produktionsrealität trifft. Sie brauchen nicht überall Komplexität. Aber wo immer doppelte Nebenwirkungen Geld, Zustand oder Vertrauen schaden würden, sollte Idempotenz ein erster-Klasse-Teil des Vertrags sein.
Dieselben Regeln gelten direkt für Hintergrund-KI-Agenten. Polling-Agenten, die Aufgaben beanspruchen, Benachrichtigungen aussenden oder Tool-Aufrufe auslösen, brauchen Entdup-Schlüssel und idempotente Claim-Protokolle genauso wie Zahlungs-APIs. Für wie das Claim-und-Entdup-Muster innerhalb von Produktions-KI-Assistenten funktioniert, siehe Polling-Agenten in KI-Assistenten: 11 Implementierungsmuster.
