Webhooks vs Polling: почему «проверим статус потом» убивает консистентность

Webhooks vs Polling: почему «проверим статус потом» убивает консистентность

Webhook — это не магия, а чужой обещанный звонок. Polling — это ваша навязчивая проверка в дверь каждые 10 секунд. Оба подхода живут только если у вас есть нормальная модель состояний, а не «created/paid/failed» в одной таблице и молитва в другой.

Если у вас webhook-only, готовьтесь к классике: событие пришло раньше записи, дубль прилетел после ретрая, подпись не сошлась, а ваша обработка уже успела списать деньги дважды. Идемпотентность или смерть. Без ключа события, дедупликации и сохранения raw payload вы не интегрируете платежи — вы устроите лотерею.

Polling-only тоже костыль на костыле. Он маскирует проблему, но не решает её: задержки растут, API ловит rate limit, а промежуточные состояния вроде pending, authorized, reversed и settled превращаются в кашу. Документация — это ложь, логи — истина: если вы не видите переходы статуса по времени, вы не контролируете сеттлмент.

Нормальная схема всегда гибридная: webhook — для триггера, polling — для верификации и добора хвостов. Стройте конечный автомат, храните версию состояния, делайте ретраи с backoff и проверяйте, что одно и то же событие не меняет итог дважды. Иначе ваш мерчант забанен без объяснения причин, а вы ещё спорите с саппортом о «редком кейсе».

Не выбирайте между пушем и опросом как между религиями. Выбирайте консистентность, дедупликацию и наблюдаемость — всё остальное очередной «убийца Stripe», который не умеет в рекурренты.