# Что значит потерять вебхук?

Потеря вебхука означает, что отправитель создал событие, но ваша система не получила или не смогла обработать его. Иногда это остаётся незамеченным. А иногда превращается в проблему, затрагивающую деньги, клиентов и репутацию компании.

Если вы разрабатываете чат-бота, потерянный вебхук может означать пропущенное сообщение пользователя. Пользователь не получит ответ на свой вопрос. Это неприятно, но не всегда критично: он может отправить сообщение ещё раз, либо проблему со временем заметит сотрудник службы поддержки.

Если вы создаёте бизнес-интеграцию с внешним сервисом, потерянный вебхук означает пропущенное событие, способное нарушить бизнес-процесс. Заказ может не попасть в CRM, статус доставки — не обновиться, счёт — не сформироваться, а команда — пропустить важное уведомление.

В банковских и платёжных интеграциях ситуация становится гораздо серьёзнее. Пропущенный вебхук с подтверждением платежа может оставить клиента в худшем из возможных состояний: деньги списаны, но ожидаемый товар, услуга или доступ не предоставлены. Даже если проблему можно исправить вручную, она увеличивает нагрузку на службу поддержки и подрывает доверие.

Когда ваша система работает в продакшене и обслуживает реальных клиентов, потеря события всегда становится проблемой. В худшем случае она может привести к финансовым убыткам, операционным сбоям и репутационному ущербу.

## Почему вебхуки теряются

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

Отдельная категория рисков возникает при изменении инфраструктуры.

Представьте, что бизнес растёт и текущий сервер больше не справляется с нагрузкой. Вы разворачиваете новый сервер и обновляете DNS-запись, чтобы домен указывал на его новый IP-адрес.

На первый взгляд всё просто. Но изменения DNS не распространяются по интернету мгновенно. Разные резолверы, интернет-провайдеры и корпоративные сети могут сохранять старый адрес в кеше в течение срока TTL, а иногда и дольше из-за особенностей собственной инфраструктуры.

В результате одни отправители уже обращаются к новому серверу, а другие продолжают отправлять вебхуки на старый. Некоторое время события могут поступать на оба сервера в непредсказуемом порядке.

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

Для чат-бота это может привести к двум одинаковым ответам на одно сообщение. В бизнес-интеграции могут появиться дублирующиеся заказы, повторные уведомления или многократная синхронизация одних и тех же данных.

В процессах, связанных с платежами, последствия могут быть особенно серьёзными. Повторная обработка одного события без надлежащей защиты от дубликатов способна привести к двойной выдаче товара, повторному зачислению средств на баланс или многократному списанию платежа.

## Потеря и дублирование — две стороны одной проблемы

Надёжная обработка вебхуков должна одновременно учитывать два сценария:

1. Событие не достигает получателя с первой попытки.
2. Одно и то же событие доставляется несколько раз.

Поэтому недостаточно просто принять HTTP-запрос и вернуть `200 OK`. Необходимо учитывать временные сбои, перезапуски приложения, миграции инфраструктуры и повторные попытки со стороны отправителя.

На практике это обычно означает следующее:

* отправитель должен повторять доставку после временных сбоев;
* получатель должен быстро подтверждать приём события, а ресурсоёмкую обработку выполнять отдельно;
* обработка должна быть идемпотентной, чтобы повторное получение события не приводило к повторению бизнес-операции;
* идентификаторы событий необходимо сохранять и использовать для обнаружения дубликатов;
* во время миграции инфраструктуры старый сервер должен оставаться доступным достаточно долго для завершения перехода;
* журналы доставки должны показывать, какие события были получены, завершились ошибкой, отправлялись повторно или обрабатывались несколько раз.

## Надёжность должна быть частью архитектуры

Вебхуки часто воспринимают как незначительную техническую деталь: один сервис отправляет запрос, другой его принимает — и на этом всё.

В действительности вебхуки нередко являются частью критически важного бизнес-процесса.

Они могут передавать сведения о платежах и заказах, сообщения клиентов, изменения подписок, обновления CRM и события внутренней автоматизации. Поэтому надёжность доставки, повторные попытки, история событий и защита от дубликатов должны закладываться в систему с самого начала, а не добавляться после первого инцидента.

Выбор надёжной платформы для работы с вебхуками имеет значение. Такая платформа должна не только принимать входящие запросы, но и помогать не терять события при временной недоступности получателя, сохранять историю доставки и безопасно отправлять события повторно при необходимости.

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

Если события важны для продукта и бизнеса, инфраструктура их доставки тоже должна быть надёжной.