Webhook или polling: как сервис узнаёт о событии
Клиент оплатил заказ десять минут назад, деньги списаны, а в личном кабинете по-прежнему «ожидает оплаты». Чтобы понять, где застряли данные, нужно знать, каким именно способом сервисы сообщают друг другу о событиях.
Две схемы
Когда одному сервису нужно узнать, что произошло в другом, вариантов ровно два: спрашивать самому или ждать, пока сообщат.
При polling инициатива у нашей стороны. Сервис раз в несколько секунд отправляет запрос вида «какой сейчас статус у заказа 123» и повторяет это, пока не получит окончательный ответ либо пока не упрётся в ограничение по времени. Бытовая аналогия — заказать пиццу навынос и каждые пять минут звонить в ресторан с вопросом, готова ли она.
При webhook инициатива у противоположной стороны. При создании заказа мы передаём платёжной системе адрес, на который следует прислать уведомление. Когда транзакция завершается, система сама отправляет на этот адрес запрос с результатом. В той же аналогии — вы оставили номер телефона, и вам позвонили, когда пицца готова.
Чем они отличаются на практике
У polling главное достоинство — надёжность в смысле контроля. Наш сервис инициирует запрос сам, ему не нужен доступный извне адрес, не нужно заботиться о том, дошло ли уведомление. Если ответ не пришёл, запрос просто повторится.
Платой за это становятся лишние запросы и задержка. Опрашивая раз в тридцать секунд, вы в среднем узнаёте о событии через пятнадцать — и при этом отправляете десятки бесполезных запросов на каждый полезный. На сотне заказов это незаметно, на сотне тысяч превращается в отдельную статью нагрузки, причём в основном на чужой API, у которого обычно есть лимиты.
Webhook даёт почти мгновенную доставку и нулевой холостой трафик. Взамен требует, чтобы у вас был адрес, доступный из интернета, и чтобы он был доступен именно в тот момент, когда отправитель решил прислать уведомление. Если в эту секунду сервис перезапускался, уведомление может быть потеряно — и вы об этом не узнаете, потому что ждать было нечего.
Отсюда практика, которую применяют почти все зрелые интеграции: webhook как основной канал, а polling — как редкая страховка для записей, по которым уведомление так и не пришло.
Где искать, когда статус завис
Вернёмся к заказу, который висит в ожидании оплаты. Дальнейшие действия зависят от того, какая схема используется, и первое, что нужно выяснить, — именно это.
Если настроен webhook, порядок такой:
1. Найти в логах входящий запрос от платёжной системы за нужное время. Проще всего искать по идентификатору заказа или транзакции. 2. Если запрос есть — посмотреть, с каким кодом мы на него ответили. Код 200 означает, что уведомление принято, и дальше проблема внутри нашей обработки. Любой другой код означает, что мы уведомление отвергли, и отправитель, скорее всего, будет пытаться ещё. 3. Если запроса нет вовсе — смотреть в личном кабинете платёжной системы, отправляла ли она его. Там обычно есть журнал доставки вебхуков с кодами ответов и числом попыток. 4. Проверить очевидное со стороны инфраструктуры: не блокирует ли адрес отправителя межсетевой экран, не истёк ли сертификат на нашем адресе, не сменился ли сам адрес после переезда.
Если работает polling, вопросы другие. Крутится ли фоновая задача опроса вообще. Не упёрлась ли она в ограничение по числу попыток и не бросила ли заказ в промежуточном статусе. Не отвечает ли внешний API ошибкой или превышением лимита запросов. Не растёт ли очередь необработанных заказов — это часто видно раньше, чем приходят жалобы.
Три ловушки, о которых стоит знать заранее
Повторные доставки. Отправитель, не получивший подтверждения, пришлёт уведомление снова — и так несколько раз. Если обработчик не умеет распознавать повтор, заказ может быть проведён дважды. Когда в заявке фигурируют дубли операций, проверять стоит в первую очередь это.
Ответ раньше обработки. Правильный обработчик вебхука отвечает быстро, а тяжёлую работу откладывает в очередь. Если он делает всё синхронно, отправитель может не дождаться ответа, счесть доставку неудачной и прислать уведомление повторно — притом что первое уже обрабатывается.
Порядок событий. Уведомления приходят не обязательно в том порядке, в каком происходили. Сообщение об отмене может опередить сообщение об оплате, и если обработчик слепо перезаписывает статус, получится ерунда. Поэтому в уведомлениях обычно есть отметка времени или номер версии.
Что спросить у разработчиков заранее
Разбор такой заявки идёт в разы быстрее, если ответы на несколько вопросов известны до инцидента: какая схема используется для каждой интеграции, где лежат логи входящих уведомлений, есть ли у платёжной системы журнал доставки и доступ к нему, сколько попыток делает отправитель и с какими интервалами, есть ли механизм повторной обработки вручную.
Последний пункт особенно полезен: во многих системах есть кнопка «переотправить вебхук» или ручной запуск сверки, и знание о ней превращает часовое расследование в минутное действие.