Zum Hauptinhalt springen

Idempotency

Einleitung​

Idempotency stellt sicher, dass die mehrfache Ausführung derselben Operation denselben Effekt hat wie die einmalige Ausführung.

In verteilten Systemen ist das kein Komfort-Feature, sondern Voraussetzung für:

  • Retries
  • Event-Redelivery
  • Transactional Outbox
  • Netzwerk-Instabilität

Grundsatz:

At-least-once Delivery verpflichtet zu Idempotenz.

Einordnung

Idempotency ist ein Micro-Pattern für Zuverlässigkeit und Stabilität.

Typische Einsatzfelder:

  • Microservices
  • Event-Driven Architecture
  • Saga-Implementierungen
  • Zahlungs- und Bestellprozesse

Es wirkt auf der Operationsebene, nicht auf Architekturebene.

Zwei Arten von Idempotenz

1️⃣ Natürliche Idempotenz​

Operation ist inhärent idempotent:

  • PUT /resource/123 mit gleichem Payload
  • Status auf „SHIPPED“ setzen
  • „Mark as processed“

Mehrfache Ausführung verändert nichts.

2️⃣ Erzwungene Idempotenz​

Operation ist nicht natürlich idempotent:

  • Zahlung ausführen
  • Bestellung anlegen
  • E-Mail versenden

Hier braucht es:

  • Idempotency-Key
  • Deduplizierung
  • Zustandsprüfung

Grundprinzip

Zentrale Mechanismen

1️⃣ Idempotency-Key​

  • Eindeutiger Identifier pro Operation
  • Vom Client generiert oder serverseitig vergeben
  • Muss stabil über Retries hinweg sein

2️⃣ Deduplizierung​

Speicherung von:

  • Key
  • Status
  • Response
  • Timestamp

Speicherorte:

  • Datenbank
  • Cache (Redis)
  • Event-Log

3️⃣ Event-Idempotenz​

Bei Event-Processing:

  • Event-ID prüfen
  • Verarbeitete IDs persistieren
  • Seiteneffekte nur einmal ausführen

Besonders kritisch bei:

  • Payments
  • Inventar
  • Reservierungen

Vorteile

  • Sichere Retries
  • Stabilität bei Netzwerkausfällen
  • Schutz vor Doppelbuchungen
  • Voraussetzung für Outbox + Saga

Risiken / typische Fallstricke

1️⃣ Unklare Key-Strategie​

Wenn Clients neue Keys pro Retry generieren:

→ Idempotenz bricht.

2️⃣ TTL zu kurz​

Keys werden gelöscht, bevor Retries eintreffen:

→ Doppelverarbeitung möglich.

3️⃣ Fehlende Seiteneffekt-Kontrolle​

Datenbank ist idempotent – aber E-Mail, Payment oder Webhook nicht.

4️⃣ Verwechslung mit Transaktionssicherheit​

Idempotenz:

  • ersetzt keine ACID-Transaktion
  • löst keine Konsistenzlogik

Sie verhindert nur doppelte Ausführung.

Wann besonders wichtig?

  • At-least-once Messaging
  • Transactional Outbox
  • Retry mit Exponential Backoff
  • Finanz- oder Bestellprozesse
  • Externe Webhooks

Wann weniger relevant?

  • Reine GET-Operationen
  • Natürlich idempotente Updates
  • Single-Process-System ohne Retries

Strategische Perspektive

Idempotenz ist:

  • die Sicherheitsleine verteilter Systeme
  • Voraussetzung für resiliente Kommunikation
  • elementar bei asynchroner Architektur

Ohne Idempotenz entstehen:

Doppelbuchungen Inkonsistente Zustände Nicht reproduzierbare Fehler

Fazit

Idempotency ermöglicht:

  • sichere Wiederholungen
  • robuste Event-Verarbeitung
  • kontrollierte Fehlerbehandlung

In verteilten Systemen ist sie kein optionales Feature – sondern integraler Bestandteil der Zuverlässigkeit.