Идемпотентность вебхука: когда Stripe отправляет одно событие комиссии трижды

За 14 месяцев мы залогировали каждый вебхук Stripe на thMenu: 312 из 100.000 событий пришли с одинаковым event_id два или три раза. Это обещание "at-least-once delivery" Stripe в конкретных цифрах — без идемпотентности три дубля в учёте комиссий.

Почему одно событие приходит трижды

Если Stripe не получает 2xx ответ за ~10 секунд, делает повтор. TCP таймауты, lambda cold starts, временные сбои DNS, даже успешная обработка с обрывом соединения до записи ответа — всё запускает повторы.

Три частых сценария: cold start Cloudflare Workers >10с, D1 batch коммит с обрывом соединения, или ручной "resend" в дашборде Stripe.

Паттерн INSERT-Claim

Защита thMenu — таблица stripe_webhook_events с event_id PRIMARY KEY. Первое действие: INSERT. Ошибка unique constraint 23505 = дубль — 200 OK no-op.

Критично: claim должен предшествовать бизнес-логике, иначе race condition.

Race Condition: события не по порядку

Реальный инцидент: customer.subscription.updated пришёл за 800мс до checkout.session.completed. UPDATE затронул 0 строк. Фикс: откат claim, ответ 503, Stripe повторит.

FAQ

Проверять подпись до или после claim? До. Verify дёшев, запись в БД дорогая.

Сколько хранить записи идемпотентности? Stripe гарантирует 30 дней; мы держим 90 дней.

Stripe повторяет вечно? Нет, максимум 3 дня.

Было полезно? Поделитесь.