WebSocket и обновления в реальном времени

«Учебный клиент получил 101 и 102, отключился на минуту, затем сервер уже хранит 103 и 104. При восстановлении нужны ровно два новых уведомления». Попросите формат запроса продолжения и обработку повторного 102. Затем добавьте случай удалённой истории: приложение должно явно получить новый снимок состояния или сигнал о невозможности продолжения, а не молча показать неполные данные.

Он восстанавливает транспорт, но не знает, какие сообщения клиент успел обработать. Для этого нужны правила идентификаторов, подтверждения или контрольной позиции и доступная история. Согласуйте, что считать обработкой: получение кадра, запись в локальное состояние или показ пользователю. Модель поможет разобрать варианты, однако обещание «ровно один раз» не возникает автоматически из WebSocket и повторного подключения.

Событие и соединение пользователя могут оказаться на разных экземплярах. Нужен способ доставки события нужному обработчику и общее понимание истории. Попросите схему с двумя серверами и рестартом одного из них. Уточните, где хранится авторизация и кто контролирует порядок; привязка соединения к одному серверу сама по себе не решает проблему потерянных уведомлений после его остановки.

На стенде оборвите сеть, замедлите чтение и дождитесь истечения сессии. Проверьте предел очереди сообщений и частоту повторных подключений, чтобы клиенты не атаковали сервис синхронными повторами. Укажите прокси и библиотеку: браузерные и серверные API heartbeat различаются. Енотик предлагает протокол и код, но фактическую доставку, нагрузку и сетевые обрывы проверяете вы в своём окружении.