Webhooks vs Polling: почему стейт ломается у тех, кто верит в «почти realtime»

Webhooks vs Polling: почему стейт ломается у тех, кто верит в «почти realtime»

Polling — это костыль для систем, которые боятся собственных вебхуков. Вы сами назначаете себе DDoS: бесконечные запросы, пустые ответы, гонка за статусом, который уже успел три раза смениться. Документация обычно обещает «простую проверку платежа», а по факту вы строите таймерный мусоросборник.

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

Проблема не в доставке события, а в консистентности. Вебхук пришёл раньше, чем ваш checkout записал order_id; polling увидел pending, когда сеттлмент уже прошёл; два канала обновили один и тот же стейт, и вот у вас двойное списание в отчётах и «разбираемся» в поддержке. Документация — это ложь, логи — истина.

Правильная схема почти всегда гибридная: вебхук как основной триггер, polling как страховка для хвостов, где событие потерялось, отвалился consumer или провайдер решил играть в тишину. Но polling не должен быть вашим источником правды — только механизмом сверки.

Если у вас нет идемпотентности, версии стейта и нормального audit trail, вы не интегрируете платежи — вы коллекционируете фантомные транзакции. Идемпотентность или смерть.