Webhooks, Long Polling и WebSockets: как не выбрать лишний протокол

Webhooks, Long Polling и WebSockets: как не выбрать лишний протокол

Webhooks — push от источника: событие случилось, сервис сам стучится к вам. Long Polling — клиент держит HTTP-запрос открытым и периодически ждёт ответ. WebSockets — постоянный двунаправленный канал, когда нужен поток сообщений без повторного рукопожатия.

Если у вас интеграция «заказ создан → обработать → записать в очередь», почти всегда берите webhooks. Ставьте 2xx только после того, как полезная нагрузка проверена, сохранена и получила idempotency key. Иначе получите повторные доставки, дубли и веселый дебаг в три часа ночи. Ловим 5xx на ровном месте — это нормально, если ретраи и дедупликация спроектированы заранее.

Long Polling нужен там, где источник не умеет пушить события или за него уже всё решено. Минусы очевидны: лишняя латентность, таймауты, нагрузка на соединения, сложнее масштабировать хендлеры. WebSockets оправданы, когда нужен интерактивный обмен в обе стороны: чаты, live-статусы, онлайн-дашборды. Для обычных событийных пайплайнов это часто пушка по воробьям.

Практическое правило: события и асинхронщина — webhooks; совместимость со старым API — long polling; постоянный двусторонний поток — websockets. Смотрим в тело запроса, верифицируем подпись, кладём сообщение в очередь и отвечаем быстро. Идемпотентность — это не роскошь, а база.