Dubbele events zijn normaal
Webhookproviders sturen soms hetzelfde event opnieuw wanneer een response te laat komt. Ook retries in je eigen flow kunnen ervoor zorgen dat een stap twee keer start. Als elke trigger blind dezelfde acties uitvoert, ontstaan dubbele records, dubbele notificaties of in het ergste geval dubbele financiële acties.
Stel dat een webshop dezelfde “order betaald”-webhook twee keer verstuurt. Zonder idempotency kan een workflow twee facturen, twee CRM-records of twee bevestigingsmails aanmaken. De trigger is dan technisch geldig, maar het businessresultaat fout. Daarom is het verwerken van dubbele events een basisvoorwaarde voor betrouwbare automation.
Gebruik een stabiele idempotency key
Koppel elke gebeurtenis aan een unieke externe ID of samengestelde sleutel en registreer welke acties al verwerkt zijn. Voor de workflow iets aanmaakt of verstuurt, controleert ze of die sleutel al bestaat. Daardoor wordt een tweede identieke trigger een veilige no-op in plaats van een dubbele uitvoering.
Een goede idempotency key komt liefst uit de bron, bijvoorbeeld een event-ID, order-ID plus actie of uniek transactienummer. Voor een side effect wordt uitgevoerd controleert de workflow of die sleutel al succesvol verwerkt is. Is dat zo, dan eindigt de tweede run gecontroleerd zonder dezelfde actie opnieuw te doen.
Denk idempotent per side effect
Niet elke stap hoeft dezelfde strategie te gebruiken. Een database-upsert, e-mailverzending en betaalactie hebben verschillende garanties. Ontwerp dus per side effect hoe duplicaten worden herkend, welke status wordt opgeslagen en wat een retry precies mag herhalen.
Let wel: verschillende acties kunnen verschillende sleutels nodig hebben. Een orderrecord updaten is niet hetzelfde als een e-mail sturen of betaling uitvoeren. Ontwerp idempotency per side effect en bewaar voldoende status om te weten of een vorige poging volledig, gedeeltelijk of helemaal niet uitgevoerd is.