Потеря вебхука означает, что отправитель создал событие, но ваша система не получила или не смогла обработать его. Иногда это остаётся незамеченным. А иногда превращается в проблему, затрагивающую деньги, клиентов и репутацию компании.
Если вы разрабатываете чат-бота, потерянный вебхук может означать пропущенное сообщение пользователя. Пользователь не получит ответ на свой вопрос. Это неприятно, но не всегда критично: он может отправить сообщение ещё раз, либо проблему со временем заметит сотрудник службы поддержки.
Если вы создаёте бизнес-интеграцию с внешним сервисом, потерянный вебхук означает пропущенное событие, способное нарушить бизнес-процесс. Заказ может не попасть в CRM, статус доставки — не обновиться, счёт — не сформироваться, а команда — пропустить важное уведомление.
В банковских и платёжных интеграциях ситуация становится гораздо серьёзнее. Пропущенный вебхук с подтверждением платежа может оставить клиента в худшем из возможных состояний: деньги списаны, но ожидаемый товар, услуга или доступ не предоставлены. Даже если проблему можно исправить вручную, она увеличивает нагрузку на службу поддержки и подрывает доверие.
Когда ваша система работает в продакшене и обслуживает реальных клиентов, потеря события всегда становится проблемой. В худшем случае она может привести к финансовым убыткам, операционным сбоям и репутационному ущербу.
Почему вебхуки теряются
Вебхук может не поступить по множеству причин: временный сбой, ошибка приложения, истёкший TLS-сертификат, перегруженная база данных, неправильно настроенный обратный прокси или проблема у поставщика инфраструктуры.
Отдельная категория рисков возникает при изменении инфраструктуры.
Представьте, что бизнес растёт и текущий сервер больше не справляется с нагрузкой. Вы разворачиваете новый сервер и обновляете DNS-запись, чтобы домен указывал на его новый IP-адрес.
На первый взгляд всё просто. Но изменения DNS не распространяются по интернету мгновенно. Разные резолверы, интернет-провайдеры и корпоративные сети могут сохранять старый адрес в кеше в течение срока TTL, а иногда и дольше из-за особенностей собственной инфраструктуры.
В результате одни отправители уже обращаются к новому серверу, а другие продолжают отправлять вебхуки на старый. Некоторое время события могут поступать на оба сервера в непредсказуемом порядке.
Если старый сервер уже выключен или больше не обрабатывает запросы, часть вебхуков может быть потеряна. Но даже если оба сервера продолжают работать, возникает другая проблема: одно событие может быть обработано дважды.
Для чат-бота это может привести к двум одинаковым ответам на одно сообщение. В бизнес-интеграции могут появиться дублирующиеся заказы, повторные уведомления или многократная синхронизация одних и тех же данных.
В процессах, связанных с платежами, последствия могут быть особенно серьёзными. Повторная обработка одного события без надлежащей защиты от дубликатов способна привести к двойной выдаче товара, повторному зачислению средств на баланс или многократному списанию платежа.
Потеря и дублирование — две стороны одной проблемы
Надёжная обработка вебхуков должна одновременно учитывать два сценария:
Событие не достигает получателя с первой попытки.
Одно и то же событие доставляется несколько раз.
Поэтому недостаточно просто принять HTTP-запрос и вернуть 200 OK. Необходимо учитывать временные сбои, перезапуски приложения, миграции инфраструктуры и повторные попытки со стороны отправителя.
На практике это обычно означает следующее:
отправитель должен повторять доставку после временных сбоев;
получатель должен быстро подтверждать приём события, а ресурсоёмкую обработку выполнять отдельно;
обработка должна быть идемпотентной, чтобы повторное получение события не приводило к повторению бизнес-операции;
идентификаторы событий необходимо сохранять и использовать для обнаружения дубликатов;
во время миграции инфраструктуры старый сервер должен оставаться доступным достаточно долго для завершения перехода;
журналы доставки должны показывать, какие события были получены, завершились ошибкой, отправлялись повторно или обрабатывались несколько раз.
Надёжность должна быть частью архитектуры
Вебхуки часто воспринимают как незначительную техническую деталь: один сервис отправляет запрос, другой его принимает — и на этом всё.
В действительности вебхуки нередко являются частью критически важного бизнес-процесса.
Они могут передавать сведения о платежах и заказах, сообщения клиентов, изменения подписок, обновления CRM и события внутренней автоматизации. Поэтому надёжность доставки, повторные попытки, история событий и защита от дубликатов должны закладываться в систему с самого начала, а не добавляться после первого инцидента.
Выбор надёжной платформы для работы с вебхуками имеет значение. Такая платформа должна не только принимать входящие запросы, но и помогать не терять события при временной недоступности получателя, сохранять историю доставки и безопасно отправлять события повторно при необходимости.
Именно для этого создан Adal: он делает доставку вебхуков предсказуемой и наблюдаемой, даже когда инфраструктура изменяется, сервис ненадолго отключается или локальный процесс не запущен.
Если события важны для продукта и бизнеса, инфраструктура их доставки тоже должна быть надёжной.