Start / Idempotenz, Exactly-Once-Illusion und Wiederholbarkeit

Idempotenz, Exactly-Once-Illusion und Wiederholbarkeit

Warum Enterprise-Systeme Wiederholung als Normalfall behandeln müssen: Idempotency Keys, deduplication, Outbox und Replay.

IdempotenzOutboxReplayMessaging
In dieser Datei
  1. Warum Exactly Once meist eine Illusion ist
  2. Idempotency Key
  3. Beispielcode
  4. Praxisübertragung
  5. Typische Fehlerbilder
Idempotenz, Exactly-Once-Illusion und Wiederholbarkeit
Idempotenz, Exactly-Once-Illusion und Wiederholbarkeit

Warum Exactly Once meist eine Illusion ist

Netzwerke, Broker und Datenbanken liefern selten Ende-zu-Ende-Exactly-Once über alle Grenzen. Robuste Enterprise-Systeme bauen deshalb auf mindestens-einmal-Zustellung plus Idempotenz, Deduplication und Reconciliation.

Idempotency Key

Der Idempotency Key gehört zu einem fachlichen Kontext: Kunde, Operation, Zeitraum und Payload-Fingerprint. Derselbe Schlüssel mit anderer Payload muss als Missbrauch oder Clientfehler behandelt werden.

Beispielcode

Idempotenz als eigener Service
package at.aydinsude.enterprise.order.application;

import java.time.Instant;
import java.util.Optional;

// Pattern: Idempotent Consumer - Wiederholung ist erwartet, nicht außergewöhnlich.
public final class IdempotencyService {
    private final IdempotencyStore store;

    public IdempotencyService(IdempotencyStore store) {
        this.store = store;
    }

    public <T> T executeOnce(String key, Class<T> resultType, java.util.function.Supplier<T> action) {
        Optional<T> previous = store.findSuccessfulResult(key, resultType);
        if (previous.isPresent()) {
            return previous.get();
        }
        store.markStarted(key, Instant.now());
        try {
            T result = action.get();
            store.markSucceeded(key, result, Instant.now());
            return result;
        } catch (RuntimeException ex) {
            store.markFailed(key, ex.getClass().getSimpleName(), Instant.now());
            throw ex;
        }
    }
}

Praxisübertragung auf das V4-Beispielprojekt

Entscheidung

Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.

Code-Nachweis

Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.

Betrieb

Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.

Typische Fehlerbilder

  • Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
  • Technische Wiederholung wird nicht idempotent gemacht.
  • Observability wird erst nach Produktionsproblem ergänzt.
  • Tests prüfen nur Happy Path und keine Wiederanläufe.
⌂ Cockpit