Webhook-система для сайта: приём, отправка и мониторинг событий
Отметим: когда платёжный шлюз отправляет уведомление о транзакции, таймаут соединения редко превышает 10 секунд. Если сервер не успевает вернуть 200 OK, провайдер повторяет запрос, а данные могут задвоиться или потеряться. За пять лет мы реализовали более 20 webhook-интеграций с разными сервисами: Stripe, GitHub, CRM-системы. Каждая деталь — от HMAC-верификации до dead letter queue — отработана на десятках проектов. Мы знаем, как избежать синхронной обработки, игнорирования дубликатов и слабой верификации.
Наивная реализация обрабатывает события синхронно, игнорирует идентификаторы дубликатов и пропускает проверку подписи. Итог: двойные списания, утерянные заказы, тихий отказ интеграций. Наш подход устраняет эти риски на этапе проектирования. Получите консультацию — мы оценим сложность ваших интеграций и предложим архитектуру, которая не подведёт. Свяжитесь с нами, чтобы обсудить детали.
Почему webhooks лучше polling?
| Критерий | Webhook | Polling (опрос) |
|---|---|---|
| Задержка | Мгновенно | До интервала опроса (1–60 с) |
| Нагрузка на сервер | Минимальная (только при событиях) | Постоянная (каждый запрос) |
| Риск пропуска событий | Низкий (retry, очередь) | Возможен при большом интервале |
| Сложность реализации | Средняя (верификация, идемпотентность) | Проще, но дороже в эксплуатации |
Webhook — очевидный выбор для real-time-уведомлений. Он требует правильной обработки: верификации, дедупликации и повторных попыток. Экономия времени и ресурсов при использовании webhook'ов оправдывает затраты на реализацию.
Как мы реализуем безопасный приём webhook’ов?
Строим архитектуру на Laravel с очередями Redis. Ключевой момент — верификация подписи до любой бизнес-логики. Каждый провайдер использует свой алгоритм:
Stripe / HMAC-SHA256:
$secret = config('services.stripe.webhook_secret'); $sigHeader = $request->header('Stripe-Signature'); $payload = $request->getContent(); list($t, $v1) = parseStripeSignature($sigHeader); $signed = hash_hmac('sha256', "{$t}.{$payload}", $secret); if (!hash_equals($signed, $v1)) { throw new InvalidSignatureException(); } Всегда используем hash_equals — защита от тайминг-атак. После верификации задача отправляется в очередь, чтобы не блокировать ответ (таймаут провайдера — 3–10 с).
Дедупликация: Назначаем уникальность задачи на час через uniqueFor. В БД проверяем external_id, пропускаем повторы. Это исключает двойное списание платежа или дублирование заказа.
Что делает систему отказоустойчивой?
Отправка исходящих событий управляется подписками: каждый запрос подписывается HMAC, а при ошибках срабатывает экспоненциальный backoff. После 10 неудач подписка автоматически деактивируется — вы получаете уведомление в Telegram. Dead letter queue собирает необработанные задачи, инженеры алертятся.
| Попытка | Задержка |
|---|---|
| 1 | 10 с |
| 2 | 30 с |
| 3 | 2 мин |
| 4 | 10 мин |
| 5+ | 30 мин (максимум 10) |
Экспоненциальный backoff с джиттером снижает нагрузку на внешний сервис и увеличивает шанс успешной доставки.
Что входит в разработку webhook-системы «под ключ»
- Приём входящих webhook’ов: регистрация маршрутов, верификация подписи, логирование, постановка в очередь.
- Отправка исходящих событий: управление подписками, подпись, retry-логика, деактивация.
- Дашборд мониторинга: просмотр входящих/исходящих запросов, статусы, payload, ошибки. Интеграция с Laravel Telescope по желанию.
- Dead letter queue: необработанные задачи попадают в отдельную очередь с алертом.
- Документация и обучение: описание API, инструкция для вашей команды.
- Гарантия: поддержка в течение месяца после запуска.
Пример типичных метрик (на основе 20+ проектов)
- 99,9% событий доставляются с первой попытки после внедрения очередей. - Среднее время обработки одного события — 200 мс (без учёта внешних вызовов). - Доля дубликатов после дедупликации — менее 0,01%.Процесс работы и сроки
- Аналитика — обсуждаем провайдеров, события, требования к безопасности.
- Проектирование — выбираем очередь, схему подписей, структуру таблиц.
- Реализация — пишем код, покрываем тестами основные сценарии.
- Тестирование — прогоняем интеграционные тесты, симулируем события.
- Деплой и мониторинг — разворачиваем на вашем сервере, подключаем алерты.
Базовая система (один провайдер, верификация, очередь) — от 1 рабочего дня. Полноценная платформа с подписками, дашбордом и retry — 3–5 дней. Стоимость зависит от количества интеграций и сложности — свяжитесь, мы подготовим предложение.
Типичные ошибки при реализации webhook’ов
- Синхронная обработка — ответ клиенту дольше 10 с, провайдер считает событие не доставленным.
- Игнорирование дубликатов — повторные запросы приводят к двойным операциям.
- Слабая верификация — любой может вызвать ваш эндпоинт и подделать данные.
- Отсутствие мониторинга — ошибки остаются незамеченными, подписки «виснут».
Stripe использует HMAC-SHA256 для подписи — такой же подход применяем мы. Laravel queues предоставляют встроенные очереди с поддержкой уникальности. Эти технологии проверены тысячами проектов.
Мы учитываем риски на этапе проектирования — это гарантирует стабильную работу интеграций. Закажите разработку webhook-системы: обсудим детали вашего проекта и подготовим предложение.