Webhook-idempotenssi: Kun Stripe Lähettää Saman Komissiotapahtuman Kolme Kertaa

14 kuukauden ajan kirjasimme jokaisen Stripe-webhookin thMenussa: 312 / 100.000 tapahtumasta saapui samalla event_id:llä kahdesti tai kolmesti. Tämä on Stripen "at-least-once delivery" -lupauksen konkreettinen luku — ilman idempotenssia kolme kaksoiskappaletta komissiokirjassa.

Miksi Sama Tapahtuma Saapuu Kolmesti

Jos Stripe ei saa 2xx-vastausta ~10 sekunnissa, se yrittää uudelleen. TCP-timeoutit, lambda cold startit, ohimenevät DNS-virheet, jopa onnistunut käsittely yhteyden katkettua — kaikki laukaisevat uudelleenyrityksen.

Kolme yleisintä skenaariota: Cloudflare Workers cold start >10s, D1 batch -transaktio commitattu mutta yhteys katkesi, tai manuaalinen "resend" Stripe-dashboardista.

INSERT-Claim-malli

thMenun puolustus on taulu stripe_webhook_events avaimella event_id PRIMARY KEY. Ensimmäinen toimi: INSERT. Unique constraint -virhe 23505 = kaksoiskappale — 200 OK no-op.

Kriittistä: claimin täytyy edeltää liiketoimintalogiikkaa race conditionin välttämiseksi.

Race Condition: Tapahtumat Väärässä Järjestyksessä

Todellinen tuotantotapaus: customer.subscription.updated saapui 800ms ennen checkout.session.completed:a. UPDATE vaikutti 0 riviin. Korjaus: claimin rollback, palauta 503, Stripe yrittää uudelleen.

FAQ

Verifioi allekirjoitus ennen vai jälkeen claimin? Ennen. Verify on halpa, DB-kirjoitus kallis.

Kuinka kauan säilyttää idempotenssirivit? Stripe takaa 30 päivän retryn; me säilytämme 90 päivää.

Yrittääkö Stripe ikuisesti? Ei, maksimissaan 3 päivää.

Oliko tästä hyötyä? Jaa se.