resilience

4 posts

Deine Retry-Schleife geht davon aus, dass der erste Request fehlgeschlagen ist. Das hat er wahrscheinlich nicht.

Ein Timeout oder Crash bedeutet nicht, dass dein API-Request verloren ging. So machen Idempotency-Keys Retrys sicher – und das Storage-Pattern, das tatsächlich Duplikate verhindert.

Dein Service stürzt mitten in einem -Request ab. Der Client sieht einen Timeout und versucht es erneut. Du hast jetzt zwei Abbuchungen. Der Kunde ist sauer.…

Ein Lock, der den Prozess überlebt: Wie distributed Leases tatsächlich funktionieren

In-Memory-Mutexes verschwinden, wenn der Server neu startet. Hier erfährst du, wie distributed Leases mit Fencing Tokens und TTLs doppelte Arbeit über Crashes hinweg verhindern – und wo sie trotzdem versagen.

Dein überlebt kein . Er überlebt keinen OOM, kein Deployment-Rollout und keinen Node-Reboot. Sobald der Prozess beendet wird, ist der Lock weg. Wenn dieser…

Ein Circuit Breaker ohne Goroutines, ohne Timer und ohne Hintergrund-Overhead

Die meisten Circuit-Breaker-Bibliotheken starten Hintergrund-Threads, um die Wiederherstellung zu prüfen. Das brauchen Sie nicht. Hier ist ein request-getriebener Entwurf, der jeglichen Hintergrund-Overhead eliminiert – ohne Korrektheit zu opfern.

Jeder Circuit Breaker, den ich in Produktion geprüft habe, startet irgendwann einen Hintergrund-Thread. Das kann eine Go-Goroutine, ein Javaoder ein…

Dein Web-Service hat einen Graceful-Shutdown-Pfad. Das ist der Bug.

Crash-only-Software behandelt jeden Fehler als Crash und jeden Start als Recovery. Für Web-Services bedeutet das, die Shutdown-Logik zu löschen und einen Zustand zu entwerfen, der ein `kill -9` überlebt.

Dein Web-Service hat einen Shutdown-Handler. Er flushed Buffer, schließt Verbindungen, schreibt Checkpoints. Du hast ihn vielleicht einmal getestet. In…