Webhooks, Long Polling и WebSockets — выбираем транспорт без самообмана

Webhooks, Long Polling и WebSockets — выбираем транспорт без самообмана

Webhook — это push: источник сам шлёт событие, вы принимаете, валидируете, отвечаете 2xx и кладёте payload в очередь. Плюсы: низкая задержка, дешёвый входящий канал, удобно для событийной архитектуры. Минусы: нужен публичный endpoint, подпись, ретраи, защита от дублей. Идемпотентность — это не роскошь, а база.

Long polling — компромисс для систем, где пуш недоступен. Клиент держит HTTP-запрос открытым, сервер отвечает, когда событие есть, затем соединение пересоздаётся. Плюсы: проще пробить через прокси и firewall, чем WebSocket. Минусы: лишняя нагрузка на HTTP-стек, таймауты, дрожание соединений, сложнее нормальный backpressure. Ловим 5xx на ровном месте, если таймауты не согласованы.

WebSockets — двунаправленный постоянный канал. Хорош для чатов, live-дашбордов, онлайн-коллаборации и всего, где нужно много мелких сообщений в обе стороны. Но это уже stateful-сессии, heartbeat, восстановление после обрыва, балансировка с sticky sessions или внешним хранилищем состояния. Прокидываем стейт через метаданные, иначе отладка превращается в археологию.

Правило простое: если вам нужны события от внешней системы — берите webhooks; если внешняя система умеет только ждать — long polling; если нужен постоянный интерактивный канал — WebSockets. Для интеграций между сервисами чаще выигрывает webhook с очередью и ретраями: меньше соединений, проще аудит, легче пережить падение соседнего сервиса.