WebSocket не нужен. Почти всегда. WebSocket создаёт иллюзию простоты: постоянное соединение, двусторонняя связь, никакой лишней обёртки. Но на практике это тяжёлый протокол и почти всегда избыточный.

Постоянное соединение — не бесплатное.

Каждое соединение — это: – выделенный TCP-сокет – память на буферы и таймеры – регулярные ping/pong пакеты – необходимость держать пользовательский state на сервере

При 100k подключениях в idle: – память: 300–500 МБ (Node.js, uWebSockets.js) – CPU: ~7% просто на поддержание соединений – одна массовая рассылка может триггерить GC и просадку latency

Масштабирование WebSocket — отдельная боль: – Sticky-сессии обязательны (иначе нельзя писать адресно) – Горизонтальное масштабирование требует внешнего pub/sub – Протокол не работает через CDN – Никаких встроенных ack, retry, QoS В большинстве задач WebSocket не нужен вообще. Альтернативы проще, стабильнее, масштабируются лучше:

– EventSource (SSE) Односторонний канал server → client. HTTP/1.1, простой протокол, балансируется обычным nginx. Подходит для realtime фидов, алертов, обновлений UI.

– Long polling Рабочий вариант. HTTP-запрос держится открытым до появления данных. Поддерживает edge-кеш, не требует сложной инфраструктуры.

– Push через REST + CDN Если данные можно кешировать даже на 1–2 секунды — дешевле отправить через pull-модель. REST + Cloudflare/Fastly + max-age — и клиент почти в real-time.

– MQTT / raw TCP Когда реально нужен duplex и контроль — лучше уйти на уровень ниже. Там можно сделать свой протокол с ack, QoS, batching.

WebSocket — это не default. Это инструмент для узкого класса задач: двусторонняя синхронизация, RTC, редакторы, игры.

Во всех остальных случаях он добавляет ресурсоёмкость, сложность и архитектурные ограничения. Без реальной пользы. Если можно не держать соединение — не держи.