Modul 8: Resilience — Systeme, die nicht fallen

Ausfälle sind normal

Netzwerke fallen, Datenbanken restarten, externe APIs ratelimiten. Resilience bedeutet nicht, Ausfälle zu verhindern (unmöglich), sondern ihnen zu begegnen: Degradation statt Totalausfall, schnelle Erholung statt langsame Hänge. Die Muster aus diesem Modul sind die Werkzeuge dafür.

Lesson 1: Timeouts — die einfachste Resilience

Ein Timeout ist die einfachste und wichtigste Resilience-Maßnahme: Kein Request darf unendlich warten. Setze Timeouts auf jeder Ebene: HTTP-Client (2-5s), Datenbank (1-3s), Queue-Consumer (30s). Ohne Timeouts breitet sich ein Ausfall wie ein Kettenreaktion aus — ein langsamer Service blockiert Threads, die dann nicht für andere Anfragen verfügbar sind.

Lesson 2: Retries mit Backoff

Flüchtige Fehler (Netzwerk-Blip, 503) verdienen einen Retry — aber nicht sofort. Exponentielles Backoff (1s, 2s, 4s, 8s) mit Jitter (Zufall) verhindert Thundering Herd: Wenn alle Clients gleichzeitig retryen, überlasten sie den Service erneut. Max 3 Retries, dann Circuit Breaker. Idempotenz ist Voraussetzung: Ein Retry darf nicht doppelt abbuchen.

# resilience4j — Retries + Circuit Breaker, deklarativ
resilience4j:
  retry:
    instances:
      payment:
        max-attempts: 3
        wait-duration: 1s
        enable-exponential-backoff: true
        exponential-backoff-multiplier: 2.0
        retry-exceptions:
          - java.io.IOException        # nur flüchtige Fehler
  circuitbreaker:
    instances:
      payment:
        sliding-window-size: 20
        failure-rate-threshold: 50    # 50 % Fehler -> Circuit öffnet
        wait-duration-in-open-state: 30s

Lesson 3: Circuit Breaker

Ein Circuit Breaker überwacht Fehler und unterbricht die Verbindung bei zu vielen Ausfällen. Drei Zustände: Closed (normal), Open (alle Requests fail-fast), Half-Open (Probier-Phase). Nach N Fehlern in einem Zeitfenster -> Open. Nach einer Wartezeit -> Half-Open, ein Probe-Request. Erfolg -> Closed, Fehler -> Open. Verhindert, dass ein langsamer Service den ganzen Stack blockiert.

Lesson 4: Bulkheads

Bulkheads isolieren Ressourcen: Ein Thread-Pool pro Service, nicht ein geteilter Pool. Fällt der Payment-Service aus, blockiert er nur den Payment-Pool, nicht den Order-Pool. In Spring: @Async mit eigenem ThreadPoolTaskExecutor pro Service. In Kubernetes: Resource Limits und separate Deployments. Bulkheads verhindern Kaskadenausfälle.

Lesson 5: Rate Limiting und Graceful Degradation

Rate Limiting schutzt vor Überlast: Token Bucket (flexibel), Leaky Bucket (glatt), Fixed Window (einfach). 429 Too Many Requests mit Retry-After. Graceful Degradation: Bei Teilausfall Features abschalten, nicht alles. Wenn die Empfehlungs-Engine fällt, zeige statische Empfehlungen. Wenn das Rating-System fällt, zeige "Bewertung deaktiviert" statt eines 500.