Stopp, nicht nochmal: Vorab-Checks schützen deine Deployments

Du kennst das Gefühl. Ein Script läuft durch, alles sieht gut aus – und plötzlich startet es nochmal. Ob durch einen Retry in der Pipeline, einen nervösen Klick oder eine falsche Konfiguration. Plötzlich werden Datenbank-Migrationen doppelt ausgeführt, Ressourcen verdoppelt oder Webhooks mehrmals ausgelöst.

Genau hier setzt eine einfache Idee an: Vor dem eigentlichen Start prüfen, ob der Vorgang schon mal gelaufen ist.

Idempotenz ist kein Freifahrtschein

Viele Teams gehen davon aus, dass ihre Scripts mehrfach laufen können, ohne Schaden anzurichten. In der Theorie klingt das vernünftig. In der Praxis reicht oft schon ein kleiner Unterschied – ein Timestamp, der sich verändert, oder ein Zähler, der hochzählt – und die doppelte Ausführung wird zum Problem.

Typische Beispiele sind:

• Das Anlegen von Cloud-Ressourcen
• Schema-Änderungen in der Datenbank
• Webhooks, die Nutzer-Registrierungen verarbeiten
• Batch-Jobs, die Daten zwischen Systemen abgleichen

Auch wenn ein Script „einigermaßen idempotent“ ist, reicht das nicht immer aus. Wer hier blind vertraut, riskiert Datenkorruption oder doppelte Kosten.

Vorab-Prüfung statt Hoffnung

Statt auf Idempotenz zu vertrauen, setzen moderne Teams auf klare Zustandsprüfungen. Bevor ein Script startet, wird abgefragt: „Wurde dieser Schritt in diesem Kontext schon ausgeführt?“

Diese Prüfung erfolgt über einen zentralen Zustandsspeicher – zum Beispiel eine Datenbank, Redis oder ein verteiltes Sperrsystem. Dort wird festgehalten, ob und wann ein Vorgang bereits lief.

Der Ablauf im Detail

1. Zustand abfragen – Vor dem Start wird geprüft, ob der Vorgang schon bekannt ist
2. Kontext prüfen – Parameter und Umgebung werden verglichen
3. Sperre setzen – Ein Flag oder Lock verhindert parallele Ausführungen
4. Logik ausführen – Das eigentliche Script läuft nur, wenn alles okay ist
5. Zustand aktualisieren – Nach erfolgreicher Ausführung wird der Status auf „fertig“ gesetzt

Dam<|eos|>