Webhooks vs Polling: кто ломает консистентность стейтов быстрее и грязнее

Webhooks vs Polling: кто ломает консистентность стейтов быстрее и грязнее

Платёжный стейт не живёт в вакууме. Он прыгает между pending, authorized, captured, failed, reversed, и если вы строите логику на одном источнике правды — готовьтесь к инцидентам. Webhook обещает «само прилетит», polling обещает «сами допросим». Оба врут, просто по-разному.

Webhooks хороши, когда у вас есть:
— идемпотентный приёмник;
— подпись, которую реально проверяют, а не для галочки;
— дедупликация по event_id;
— очередь, а не прямой вызов бизнес-логики;
— таймауты, ретраи и журнал сырого payload. Документация — это ложь, логи — истина.

Polling нужен не как замена, а как страховка от потерянных событий, рассинхрона и кривых ретраев провайдера. Если вебхук не пришёл, пришёл дважды или пришёл в неправильном порядке, ваш job должен сверять состояние и уметь откатывать фантомные успехи. Иначе получите классический костыль: в кабинете оплата «успешна», в бухгалтерии холд, в проде паника.

Золотое правило: webhooks пишут стейт, polling его валидирует. Не наоборот. И никогда не стройте критическую бизнес-логику на факте доставки события — стройте её на переходе стейта с защитой от повторов и out-of-order.

Идемпотентность или смерть: сначала нормальная модель состояний, потом вебхуки, потом сверка по polling, потом уже попытки изображать финтех-магии.