Idempotenz in verteilten Systemen

Es gibt einen Satz, an dem sich erfahrene von unerfahrenen Backend-Teams unterscheiden: „Diese Nachricht kann doppelt ankommen." Wer verteilte Systeme lange genug betreibt, hört auf, sich Duplikate wegzuwünschen, und beginnt, für sie zu bauen. Denn das Duplikat ist kein Bug, den man beseitigt — es ist eine unvermeidliche Folge davon, dass Nachrichten über ein Netz reisen, das jederzeit Antworten verschlucken kann.

Die einzige verlässliche Antwort darauf heißt Idempotenz: Eine Operation ist idempotent, wenn ihre mehrfache Ausführung denselben Zustand erzeugt wie eine einzige. Ist eine Abbuchung idempotent, macht ein doppelt zugestellter „Bezahle"-Befehl keine zweite Abbuchung. Dieser Text erklärt, warum Duplikate zwingend entstehen, warum „exactly-once" eine Illusion ist, und wie man mit Idempotency Keys, HTTP-Semantik, Outbox und Inbox Systeme baut, die doppelte Zustellung und wiederholte Ausführung ertragen — framework-, queue- und cloud-neutral. Die Werkzeuge unterscheiden sich je nach Stack; das Prinzip nicht.

Warum Duplikate entstehen

Die Wurzel aller Duplikate ist ein einziges, unlösbares Problem: Wenn ein Absender eine Anfrage schickt und keine Antwort bekommt, kann er nicht wissen, was passiert ist. Drei Fälle sehen für ihn identisch aus — die Anfrage kam nie an; sie kam an und wurde verarbeitet, aber die Antwort ging verloren; sie ist noch unterwegs. Der Absender sieht nur: keine Antwort. Und die einzige Handlung, die den ersten Fall heilt, ist ein erneuter Versuch — der im zweiten Fall ein Duplikat erzeugt.

Schema: Der Server kann nicht unterscheiden, ob die erste Anfrage neu ist oder eine Wiederholung — und bucht ohne Idempotenz zweimal ab.

Diese Konstellation entsteht überall: Ein Timeout im Client löst eine Wiederholung aus. Ein Load Balancer leitet eine Anfrage nach einem kurzen Ausfall erneut weiter. Eine Queue stellt eine Nachricht ein zweites Mal zu, weil der Consumer abstürzte, bevor er sie bestätigen konnte. Ein Netzwerk-Hiccup wiederholt ein Paket. Keiner dieser Fälle ist ein Fehler in der Software — sie sind der Normalbetrieb eines verteilten Systems. Duplikate sind nicht die Ausnahme, auf die man reagiert, sondern die Regel, für die man baut.

Exactly-once vs. At-least-once

Für die Zustellung von Nachrichten gibt es drei denkbare Garantien, und ihr Verständnis entscheidet über den ganzen Entwurf.

At-most-once liefert höchstens einmal: kein Duplikat, aber möglicher Verlust — brauchbar nur, wo ein verlorenes Ereignis egal ist. At-least-once liefert mindestens einmal: kein Verlust, aber mögliche Duplikate — der ehrliche Normalfall jeder ernsthaften Queue und jedes Retry-Mechanismus. Exactly-once-Zustellung ist im allgemeinen Fall unmöglich, weil sich Zustellen und Bestätigen über ein Netz nicht atomar verbinden lassen: Zwischen „verarbeitet" und „bestätigt" kann immer etwas abstürzen.

Was Systeme „exactly-once" nennen, ist deshalb fast nie exactly-once-Zustellung, sondern at-least-once-Zustellung plus idempotente Verarbeitung — zusammen ergibt das „effectively-once": Die Nachricht kommt vielleicht mehrfach an, aber ihre Wirkung tritt genau einmal ein. Das ist der einzige erreichbare und der einzige nötige Zustand.

Der Grund, warum exactly-once-Zustellung nicht geht, ist derselbe Lost-ACK wie zuvor, nur eine Ebene höher: Der Broker müsste die Nachricht zustellen und im selben, unteilbaren Moment die Bestätigung des Consumers erhalten — doch zwischen beiden liegt ein Netz, das die Bestätigung verschlucken kann. Wie clever man es auch dreht, es bleibt ein Fenster, in dem der Broker nicht weiß, ob der Consumer die Nachricht bekam. Er kann nur wählen: im Zweifel erneut zustellen (at-least-once) oder im Zweifel nicht (at-most-once). Ein „genau einmal" ohne dieses Fenster gibt es nicht — nur die Wahl, auf welcher Seite des Zweifels man irren will.

Die Empfehlung: Entwerfen Sie für at-least-once und machen Sie die Verarbeitung idempotent; behandeln Sie Versprechen von „exactly-once-Zustellung" mit Misstrauen. Der Preis ist, dass jede zustandsändernde Verarbeitung Dedup-Logik tragen muss, statt sich auf die Infrastruktur zu verlassen. Anders entscheiden wir bei Daten, deren Verlust folgenlos ist — etwa unkritische Telemetrie; dort genügt at-most-once, und man spart sich die Idempotenz ganz.

Idempotency Keys

Der allgemeinste Weg, eine an sich nicht idempotente Operation idempotent zu machen, ist der Idempotency Key: ein eindeutiger Schlüssel, den der Absender pro logischer Operation erzeugt und mitschickt. Der Server führt einen Speicher, der Schlüssel auf Ergebnis abbildet. Kommt ein Schlüssel zum ersten Mal, wird die Operation ausgeführt und das Ergebnis unter dem Schlüssel abgelegt. Kommt derselbe Schlüssel erneut, liefert der Server das gespeicherte Ergebnis zurück, ohne die Operation noch einmal auszuführen.

Schema: Derselbe Schlüssel liefert beim zweiten Mal dasselbe Ergebnis — ohne die Wirkung ein zweites Mal auszulösen.

Drei Details entscheiden über die Korrektheit. Der Schlüssel muss die logische Operation identifizieren, nicht die technische Anfrage — bei einer Zahlung also den Bezahlvorgang, nicht den HTTP-Aufruf. Der Speicher braucht neben „fertig, Ergebnis X" auch einen Zustand „in Arbeit", sonst führen zwei gleichzeitig eintreffende Duplikate die Operation beide aus, bevor eines gespeichert hat. Und die Aufbewahrungsdauer muss mindestens so lang sein wie das größte Wiederholungsfenster, sonst läuft der Schlüssel ab, bevor die letzte Wiederholung eintrifft.

Die Empfehlung: Versehen Sie zustands- oder geldändernde Befehle mit einem vom Absender erzeugten Idempotency Key und einem Speicher, der auch den Zustand „in Arbeit" kennt. Der Preis ist ein zusätzlicher Speicher mit eigener Konsistenz und Aufräumpflicht sowie die Koordination des Schlüssels über Systemgrenzen. Anders entscheiden wir bei Operationen, die von Natur aus idempotent sind — dazu gleich mehr; dort ist der Key überflüssige Mechanik.

HTTP-Idempotenz

Das HTTP-Protokoll trägt eine Vorstellung von Idempotenz bereits in sich, und sie richtig zu nutzen spart eigene Mechanik.

GET, PUT und DELETE sind laut Spezifikation idempotent: Ein PUT, das einen Zustand setzt, kann man beliebig oft senden, das Ergebnis bleibt gleich; ein DELETE löscht beim zweiten Mal nichts mehr. POST und PATCH sind es nicht — ein POST, der eine Ressource erzeugt oder eine Zahlung auslöst, erzeugt beim zweiten Mal eine zweite. Genau diese brauchen einen Idempotency Key.

Ein Vorbehalt ist wichtig: Idempotent laut Methode heißt nicht idempotent in der Umsetzung. Ein PUT, das intern anhängt statt zu setzen, ist trotz der Methode nicht idempotent. Die HTTP-Semantik ist ein Versprechen, das man einlösen muss, kein Automatismus.

Die Empfehlung: Wählen Sie idempotente Methoden, wo die Semantik es zulässt — bevorzugt setzen statt anhängen —, und verlangen Sie bei nicht idempotenten Operationen einen Idempotency Key. Der Preis ist, dass man Operationen manchmal umständlicher als „setzen" formulieren muss, statt bequem zu inkrementieren. Anders entscheiden wir, wenn die fachliche Bedeutung zwingend nicht idempotent ist — etwa „füge einen Eintrag zu einem Protokoll hinzu"; dann trägt der Key die Verantwortung, nicht die Methode.

Queue-Verarbeitung

Nachrichten-Queues stellen fast immer at-least-once zu. Der Grund ist derselbe Lost-ACK: Ein Consumer verarbeitet eine Nachricht, stürzt aber ab, bevor er sie bestätigt — also stellt die Queue sie erneut zu. Auch abgelaufene Sichtbarkeitsfenster und Rebalancing führen zu erneuter Zustellung. Die Konsequenz ist unausweichlich: Ein Consumer darf sich nie auf einmalige Zustellung verlassen, er muss idempotent sein.

Idempotenz im Consumer kann aus mehreren Quellen kommen:

Zentral ist außerdem die Reihenfolge von Wirkung und Bestätigung: Man bestätigt eine Nachricht erst, nachdem ihre Wirkung dauerhaft festgeschrieben ist. Wer zuerst bestätigt und dann schreibt, verliert die Nachricht bei einem Absturz dazwischen.

Die Empfehlung: Behandeln Sie jeden Consumer als at-least-once und sichern Sie seine Wirkung über eine der genannten Quellen ab; bestätigen Sie erst nach dem dauerhaften Commit. Der Preis ist ein Dedup-Mechanismus je Consumer und die Sorgfalt, Wirkung und Bestätigung richtig zu ordnen. Anders entscheiden wir bei natürlich idempotenten Handlern — etwa einem, der nur einen Wert auf den in der Nachricht enthaltenen Stand setzt; dort ist keine zusätzliche Dedup-Schicht nötig.

Zahlungen

Kein Bereich zeigt die Kosten fehlender Idempotenz so unerbittlich wie Zahlungen. Eine doppelte Abbuchung ist nicht ein stiller Datenfehler, sondern ein sichtbarer Schaden beim Kunden, ein Support-Fall und ein Vertrauensbruch. Genau hier ist der Lost-ACK am gefährlichsten: Der „Bezahle"-Befehl ist die Operation, die man am wenigsten doppelt ausführen darf, und die am ehesten wiederholt wird.

Die Absicherung zieht sich über die ganze Kette. Der Client erzeugt pro Bezahlvorgang — nicht pro Klick — einen Idempotency Key. Der eigene Dienst dedupliziert darauf, sodass eine wiederholte Anfrage keine zweite Zahlung anstößt. Und der Zahlungsanbieter selbst nimmt einen Idempotency Key entgegen und dedupliziert auf seiner Seite. Jede Stufe verlässt sich darauf, dass die nächste den Schlüssel respektiert; keine Stufe verlässt sich darauf, dass es „schon nicht zweimal passiert".

Die Empfehlung: Führen Sie einen Idempotency Key pro Bezahlvorgang durch die gesamte Kette — Client, eigener Dienst, Anbieter — und machen Sie den „Bezahle"-Befehl strikt idempotent. Der Preis ist Koordination über Systemgrenzen und ein Schlüssel, der sauber am Bezahlvorgang hängen muss, nicht an der technischen Anfrage. Anders entscheiden wir nie: Bei Geld gibt es keinen Gegenfall, in dem wir auf Idempotenz verzichten.

Wiederholungen

Wiederholungen sind der Mechanismus, der aus at-least-once erst Wirklichkeit macht — und zugleich die Hauptquelle von Duplikaten. Ohne Retries verliert man Nachrichten bei jedem transienten Fehler; mit Retries erzeugt man Duplikate. Das ist kein Widerspruch, sondern der Grund, warum Retries und Idempotenz zusammengehören: Man wiederholt gefahrlos nur, was idempotent ist. Eine nicht idempotente Operation zu wiederholen ist genau der Weg, auf dem eine doppelte Abbuchung entsteht.

Sichere Wiederholungen brauchen mehr als ein try again. Sie brauchen exponentielles Backoff mit Zufallsanteil, damit nicht alle Clients gleichzeitig erneut zuschlagen und einen Retry-Sturm auslösen. Sie brauchen eine Obergrenze, damit ein dauerhaft kaputter Vorgang nicht ewig kreist. Sie müssen wiederholbare Fehler — Timeout, Netzfehler, vorübergehende Überlast — von nicht wiederholbaren unterscheiden, denn eine abgelehnte Eingabe wird durch Wiederholung nicht gültig. Und sie brauchen einen Endpunkt für Aufgegebenes, eine Dead-Letter-Ablage, statt es still zu verlieren.

Die Empfehlung: Wiederholen Sie nur idempotente Operationen, mit Backoff, Zufallsanteil, Obergrenze und einem Dead-Letter-Pfad. Der Preis ist zusätzliche Logik und ein Ort, an dem gescheiterte Nachrichten liegen und beobachtet werden müssen. Anders entscheiden wir bei einer Operation, die nicht idempotent gemacht werden kann und deren Wiederholung Schaden anrichten würde; dann wiederholt man nicht automatisch, sondern eskaliert den Fehler an einen Menschen oder einen bewusst gebauten Ausgleichsschritt.

Outbox-Pattern

Ein besonders tückisches Problem entsteht an der Grenze zwischen Datenbank und Nachrichten-Broker: das Dual-Write-Problem. Ein Vorgang soll einen Zustand ändern und ein Ereignis veröffentlichen — aber es gibt keine gemeinsame Transaktion über Datenbank und Broker. Schreibt man zuerst die Datenbank und veröffentlicht dann, geht das Ereignis bei einem Absturz dazwischen verloren. Veröffentlicht man zuerst und schreibt dann, ist das Ereignis eine Lüge, wenn das Schreiben scheitert.

Das Outbox-Pattern löst das, indem es beide Schreibvorgänge in eine Transaktion bringt. Das Ereignis wird nicht direkt veröffentlicht, sondern in derselben Datenbanktransaktion wie die Zustandsänderung in eine Outbox-Tabelle geschrieben — atomar, also entweder beides oder nichts. Ein separater Relay-Prozess liest die Outbox und veröffentlicht die Ereignisse an den Broker, markiert sie danach als gesendet.

Schema: Zustand und Ereignis werden atomar geschrieben; der Relay stellt at-least-once zu, der Consumer dedupliziert.

Weil der Relay zwischen Veröffentlichen und Markieren abstürzen kann, ist die Zustellung wieder at-least-once — das Ereignis kann doppelt beim Broker landen. Das ist in Ordnung, solange die Empfänger idempotent sind. Die Outbox garantiert, dass kein Ereignis verloren geht und keines gesendet wird, das nicht wirklich passiert ist; die Duplikate fängt die andere Seite.

Die Empfehlung: Lösen Sie jedes gemeinsame Schreiben von Zustand und Ereignis über eine Outbox in derselben Transaktion, statt direkt zu veröffentlichen. Der Preis ist eine zusätzliche Tabelle, ein Relay-Prozess und die Duplikate, die er erzeugt. Anders entscheiden wir, wenn kein Ereignis das System verlässt — wenn Zustandsänderung und Wirkung in derselben Datenbank liegen; dann gibt es kein Dual-Write und keinen Bedarf für eine Outbox.

Inbox-Pattern

Die Outbox sichert die Absenderseite; die Inbox sichert die Empfängerseite und ist ihr Spiegel. Um ein Duplikat zuverlässig zu erkennen, speichert der Consumer die ID jeder verarbeiteten Nachricht in einer Inbox-Tabelle — und zwar in derselben Transaktion wie die Wirkung. Findet er eine ID bereits vor, überspringt er die Nachricht.

Der entscheidende Punkt ist die gemeinsame Transaktion. Weil Dedup-Eintrag und Wirkung atomar zusammen festgeschrieben werden, gibt es keinen Zustand, in dem die Wirkung eingetreten, aber die ID nicht gespeichert wäre — oder umgekehrt. Genau das trennt eine korrekte Dedup von einer scheinbaren: Prüft man die ID in einer eigenen Transaktion und wirkt in einer anderen, kann ein Absturz dazwischen beides entkoppeln, und ein Duplikat schlüpft durch oder eine Nachricht geht verloren.

Zusammen ergeben Outbox und Inbox die durchgehende Kette: Der Absender verliert nichts (Outbox), der Empfänger wirkt genau einmal (Inbox), und dazwischen darf die Zustellung ruhig doppeln. Das ist „effectively-once" über den ganzen Nachrichtenweg.

Die Empfehlung: Deduplizieren Sie im Consumer über eine Inbox-Tabelle, deren Eintrag in derselben Transaktion wie die Wirkung festgeschrieben wird. Der Preis ist eine weitere Tabelle mit Aufräumpflicht und eine Transaktion, die Dedup und Wirkung umschließt. Anders entscheiden wir, wenn die Wirkung selbst schon idempotent ist — eine eindeutige Constraint oder ein bedingtes Update; dann übernimmt die Datenbank die Dedup, und eine eigene Inbox wäre doppelt gemoppelt.

Häufige Fehler

Die wiederkehrenden Muster, an denen Idempotenz scheitert:

• Auf „exactly-once"-Zustellung vertrauen, die es nicht gibt, statt at-least-once anzunehmen.
• Consumer, die einmalige Zustellung voraussetzen und keine Dedup tragen.
• Nicht idempotente Operationen automatisch wiederholen — der direkte Weg zur Doppelabbuchung.
• Dedup-Prüfung und Wirkung in getrennten Transaktionen, sodass ein Absturz dazwischen beides entkoppelt.
• Einen Idempotency Key ohne Ablauf speichern (unbegrenzter Speicher) oder mit zu kurzem Ablauf (Fenster kleiner als die Wiederholung).
• Einen nicht eindeutigen Schlüssel wählen — einen Zeitstempel, eine geratene ID —, der Kollisionen oder Lücken erlaubt.
• Bestätigen, bevor die Wirkung dauerhaft festgeschrieben ist — die Nachricht geht bei einem Absturz verloren.
• Zustand und Ereignis doppelt schreiben ohne Outbox — verlorene oder erfundene Ereignisse.
• Den Zustand „in Arbeit" vergessen, sodass zwei gleichzeitige Duplikate beide verarbeiten.
• Sich für Korrektheit auf die Reihenfolge der Nachrichten verlassen, die at-least-once nicht garantiert.

Entscheidungs-Checkliste

Fragen vor jeder zustandsändernden Verarbeitung. Es sind Diagnosefragen, keine Urteile.

• Ändert diese Operation Zustand oder Geld? Wenn ja, muss sie idempotent sein — ohne Ausnahme bei Geld.
• Ist sie von Natur aus idempotent, oder braucht sie Schlüssel oder Dedup? Natürliche Idempotenz ist die billigste.
• Gibt es einen eindeutigen Schlüssel pro logischer Operation, erzeugt vom Absender? Nicht pro technischer Anfrage.
• Werden Dedup und Wirkung in derselben Transaktion festgeschrieben? Getrennt ist es keine echte Dedup.
• Bestätigen wir erst nach dem dauerhaften Commit der Wirkung? Sonst droht Verlust.
• Reicht die Aufbewahrung des Schlüssels über das größte Wiederholungsfenster? Sonst läuft er zu früh ab.
• Behandeln wir gleichzeitige Duplikate, nicht nur aufeinanderfolgende? Dafür braucht es einen „in Arbeit"-Zustand.
• Überschreiten wir die Grenze Datenbank/Broker? Wenn ja: Outbox und Inbox.
• Sind Wiederholungen begrenzt, mit Backoff, Zufallsanteil und Dead-Letter-Pfad? Sonst drohen Sturm und stiller Verlust.

FAQ

Gibt es nicht exactly-once bei modernen Brokern? Was Broker so nennen, ist meist effectively-once innerhalb ihrer eigenen Grenze — Dedup im Broker plus transaktionale Bestätigung. Sobald eine Nachricht eine Wirkung außerhalb des Brokers auslöst, etwa eine Abbuchung, gilt wieder at-least-once, und die Idempotenz liegt bei Ihnen. Die Garantie endet an der Grenze des Brokers.

Reicht nicht eine eindeutige Constraint? Oft ja — eine eindeutige Constraint ist eine Form von Idempotenz: Der zweite Einfügeversuch scheitert. Wichtig ist, dass der Schlüssel die logische Operation abbildet und dass man den Kollisionsfall sauber behandelt, also „existiert bereits" als Erfolg mit dem bestehenden Ergebnis wertet, nicht als Fehler.

Wie lange behalten wir Idempotency Keys? Mindestens so lange wie das größte Fenster, in dem eine Wiederholung eintreffen kann — inklusive Retries, Redeliveries und manueller Wiederholungen. Danach darf der Schlüssel ablaufen. Zu kurz, und eine späte Wiederholung wird als neu behandelt; unbegrenzt, und der Speicher wächst ewig.

Was, wenn zwei Duplikate gleichzeitig ankommen? Ein reiner Ergebnis-Speicher reicht dann nicht, weil beide starten, bevor eines gespeichert hat. Man braucht einen „in Arbeit"-Zustand oder eine Sperre auf dem Schlüssel: Das erste Duplikat belegt ihn, das zweite wartet oder wird abgewiesen. Erst das macht Idempotenz auch unter Nebenläufigkeit korrekt.

Braucht jede Operation Idempotenz? Nein. Reine Lesevorgänge brauchen sie nicht, und natürlich idempotente Operationen — einen Wert setzen, per ID löschen — tragen sie schon in sich. Der Aufwand gilt zustands- und geldändernden Operationen, die nicht schon von sich aus idempotent sind. Alles andere wäre Mechanik ohne Gegenwert.

Outbox oder eine Broker-Transaktion? Die Outbox funktioniert überall, ohne besondere Broker-Fähigkeiten, weil sie nur eine Datenbanktransaktion braucht. Bietet der Broker eine echte transaktionale Kopplung an die Datenbank, kann man sie abwägen — aber die Outbox ist der portable, framework- und cloud-neutrale Standardweg.

Weiterführend

• Idempotenz — die kompakte Definition des Begriffs.
• Queue oder synchrone Verarbeitung und Asynchrone Verarbeitung einführen — wann Queues sinnvoll sind und wie man sie einführt.
• API-Versionierung ohne Kunden zu brechen — Idempotency Keys sind Teil eines belastbaren API-Vertrags.
• Zero-Downtime-Datenbankmigrationen — dieselbe Disziplin der Wiederholbarkeit, angewandt auf Backfills.

Grundlage ist die Batunet Engineering Method: für den Fehlerfall entwerfen, in kleinen umkehrbaren Schritten bauen, Beobachtbarkeit ab Tag eins.

Ein verteiltes System, das man nicht doppelt zustellen darf, ist ein System, das man nicht bauen kann. Das ehrliche Ziel ist nicht, Duplikate zu verhindern, sondern sie so folgenlos zu machen, dass niemand sie je bemerkt.