Voorkom dat scripts twee keer draaien: slimme validatie vooraf

Iedereen kent het wel. Een deployment-script draait netjes, maar opeens gaat het nog een keer. Of het nu komt door een automatische retry, een handmatige herstart of een mislukte CI/CD-pipeline, het resultaat is hetzelfde: het script voert dezelfde acties opnieuw uit. En dat kan voor flinke schade zorgen.

Denk aan dubbele database-migraties, dubbele infrastructuur of webhooks die meerdere keren worden afgevuurd. Precies daarom is het slim om vóór elke uitvoering te controleren of die al eerder heeft plaatsgevonden.

De valkuil van idempotentie

Veel teams gaan ervan uit dat hun scripts idempotent zijn. Dat wil zeggen dat ze meerdere keren achter elkaar kunnen draaien zonder extra effect. In de praktijk blijkt dat vaak niet zo te werken.

Een script dat AWS-resources aanmaakt kan bij een tweede run dezelfde resources opnieuw proberen aan te maken. Een migratie die een schema aanmaakt kan falen als de tabel al bestaat. En een webhook die een betaling verwerkt kan een klant twee keer dezelfde melding sturen. Ook al lijkt alles netjes, de gevolgen van een herhaling zijn vaak niet te voorzien.

State-validatie als alternatief

In plaats van blindelings vertrouwen te hebben in de werking van een script, is het beter om expliciet bij te houden wat al is uitgevoerd. Met pre-execution validation vraag je vóór elke run: “Is dit al een keer gedaan in deze context?”

Dat doe je met een centrale opslag van uitvoeringsstatus. Of dat nu via een database, Redis, een hash of een distributed lock gaat, het principe is altijd hetzelfde: je weet of je wel of niet moet doorgaan.

Hoe het werkt

1. Query de status – Vraag op of de uitvoering al is geregistreerd
2. Controleer context – Kijk of de parameters en omgeving overeenkomen met een vorige run
3. Vergrendel – Markeer de uitvoering als “bezig” om gelijktijdige runs te voorkomen
4. Voer uit – Draai de echte logica
5. Update status – Markeer de run als afgerond met een timestamp

Waarom dit belangrijk is voor hosting en infrastructuur

Bij NameOcean merken we dat dit type validatie vooral van belang is voor DNS-wijzigingen, SSL-provisioning en domain-registration-processen. Deze operaties mogen nooit twee keer achter elkaar gebeuren.

Het voorkomt bijvoorbeeld dat:

• DNS-records in twee regio’s tegelijk worden aangemaakt
• SSL-certificaten worden gedupliceerd
• Registraties of renewals worden dubbel uitgevoerd

In een distributed systeem of CI/CD-pipeline is het belangrijk dat je deze risico’s niet aan het script zelf laat, while