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-системи: обговоримо деталі вашого проєкту та підготуємо пропозицію.