Способы надёжной доставки 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.