Способи надійної доставки WebHooks
У попередньому пості я вже писав, що "просто отримувати вебхуки" — це далеко не просто! Цього разу я розповім про інструменти, які я пробував у своїй практиці та про їх обмеження.
Наприклад, tunnel-сервіси на кшталт ngrok чудово допомагають швидко отримати webhook на локальну машину.
Але tunnel — це просто tunnel.
Якщо ваш ноутбук був вимкнений 10 хвилин — webhook втрачено.
Якщо endpoint тимчасово недоступний — webhook втрачено.
Якщо destination відповів 500 — далі все залежить від того, чи помітили ви це взагалі.
Так, можна сказати: «Ну так підніміть нормальний сервер.»
І саме так зазвичай все і починається.
Потім з'являється черга.
Потім retries.
Потім логування.
Потім replay.
Потім кілька destinations.
Потім спроби зрозуміти, чому webhook “іноді не приходить”.
Потім з'ясовується, що provider відправляє запити нестабільно.
Потім виявляється, що retry без idempotency ламає бізнес-логіку.
Потім з'являються race conditions.
Потім — “а давайте ще історію запитів”.
І раптово «простий webhook receiver» перетворюється на окрему інфраструктурну систему.
Причому це не якась унікальна проблема.
Наприклад, SMTP — теж простий протокол. Але компанії все одно використовують Postmark, SendGrid та інші сервіси доставки пошти.
Тому що «відправити HTTP-запит» — легко. Але зробити це надійно, прозоро і передбачувано в production — вже зовсім інше завдання.
Я також пробував підхід «ну просто зберігати все в RabbitMQ».
Але черга сама по собі не вирішує проблему спостережуваності.
Вона не відповідає на питання:
— що саме прийшло;
— куди було відправлено;
— скільки було спроб;
— яку відповідь повернув destination;
— чи можна повторити конкретну доставку;
— чому частина destinations отримала webhook, а частина — ні.
Потім починаються самописні таблиці, статуси, retry-політики, retention, cleanup-job’и та UI для налагодження. Тобто в результаті ти все одно будуєш окремий reliability layer. Саме в цей момент я зрозумів, що проблема не в «отриманні webhook». Проблема — в передбачуваній доставці.
Щоб запит:
— не зникав;
— не губився при тимчасових проблемах;
— був видимим;
— міг бути повтореним;
— доставлявся однаково і прозоро.
Без магії. Без прихованих модифікацій. Без AI-«оптимізацій». Без чорних ящиків.
Просто зрозуміла і надійна система доставки webhook’ів.
Саме тому я і почав робити Adal.
No AI. No surprises. Predictable webhook delivery.