Idempotence Webhooku: Když Stripe Vystřelí Stejnou Událost Provize Třikrát

Po 14 měsíců jsme logovali každý Stripe webhook na thMenu: 312 ze 100.000 událostí přišlo se stejným event_id dvakrát nebo třikrát. To je slib "at-least-once delivery" Stripe v konkrétních číslech — bez idempotence tři duplikáty v knize provizí.

Proč Stejná Událost Přichází Třikrát

Pokud Stripe neobdrží odpověď 2xx do ~10 sekund, opakuje. Timeouty TCP, cold starty lambda, přechodné selhání DNS, dokonce úspěšné zpracování s přerušeným spojením — vše spouští opakování.

Tři časté scénáře: cold start Cloudflare Workers >10s, transakce D1 batch commitnuta ale spojení přerušeno, nebo manuální "resend" v dashboardu Stripe.

Vzor INSERT-Claim

Obrana thMenu je tabulka stripe_webhook_events s event_id PRIMARY KEY. První akce: INSERT. Chyba unique constraint 23505 = duplikát — 200 OK no-op.

Kritické: claim musí předcházet business logice, jinak race condition.

Race Condition: Události Mimo Pořadí

Skutečný incident: customer.subscription.updated přišlo 800ms před checkout.session.completed. UPDATE ovlivnil 0 řádků. Oprava: rollback claim, návrat 503, Stripe opakuje.

FAQ

Ověřit podpis před nebo po claim? Před. Verify je levný, zápis DB drahý.

Jak dlouho uchovávat řádky idempotence? Stripe garantuje 30 dní retry; držíme 90 dní.

Opakuje Stripe navždy? Ne, maximálně 3 dny.

Bylo to užitečné? Sdílejte to.