Нужна ли реализация веб-сокетов

Что проверяют

Умеете ли вы выбирать транспорт под задачу, а не тащить самый модный. Вопрос почти всегда звучит про конкретную фичу, и половина оценки это уточняющие вопросы: кто инициирует обновления, как часто они приходят, сколько клиентов держат вкладку открытой, насколько критична задержка.

Как отвечать

Сформулируйте критерий: веб-сокеты оправданы, когда обмен двусторонний, событий много и задержка важна. Чат, совместное редактирование, живая карта курьера, биржевой стакан. Если данные идут только от сервера к клиенту, достаточно Server-Sent Events: это обычный HTTP, проходит через прокси, сам переподключается и восстанавливает пропущенное по Last-Event-ID. Если обновления редкие и терпят десятки секунд, хватит опроса по таймеру, а long polling сегодня берут разве что ради совместимости со старым стеком.

Дальше назовите цену. Открытое соединение это состояние на сервере на всю сессию: память, дескриптор, привязка клиента к конкретному инстансу. Поверх сокета приходится писать руками то, что в HTTP уже есть: переподключение с нарастающей паузой, heartbeat, догрузку пропущенных событий, авторизацию (задать заголовки у браузерного WebSocket нельзя, токен идёт первым сообщением или разовым тикетом в URL).

Сильный ответ звучит так: «здесь взял бы SSE, а на сокеты перешёл бы, когда появится ввод от клиента».

Где спотыкаются

Повторяют, что сокеты снижают нагрузку на сервер. Они убирают накладные расходы на установку соединений, но добавляют постоянное состояние на каждого клиента, и масштабировать их горизонтально сложнее, чем набор stateless-запросов.

Второе: не думают про разрыв. Мобильная сеть, засыпающая вкладка, прокси с таймаутом на простой. Интерфейс обязан показывать состояние соединения и после реконнекта догружать то, что пришло без него.

Третье: приносят сокеты туда, где нужен запрос и ответ. Загрузка списка, поиск, форма прекрасно живут в обычном HTTP с кэшированием и повторами, а через сокет теряют коды ответа, ретраи и кэш.