Зачем разбирать эту тему
Realtime не означает обязательный WebSocket. Для небольшого кабинета polling раз в несколько секунд остаётся простым и устойчивым решением, если события редкие и небольшая задержка допустима.
Как устроена задача на практике
SSE удобен, когда сервер в основном отправляет события клиенту: уведомления, статусы задач, новые сообщения. WebSocket оправдан при частом двустороннем обмене — typing, presence, совместном редактировании.
Что важно в production
Сам транспорт не решает доставку. Сообщению нужны ID, серверное время, порядок, повторная доставка и read receipts как данные, а не как визуальная галочка.
Типичные ошибки
Главная ошибка — выбирать технологию или паттерн раньше, чем сформулирован пользовательский сценарий и ограничения. Второй частый промах — проверять решение только на идеальном happy path и не продумывать восстановление после сбоя, повторный запрос и права доступа.
Практический вывод
Хорошая архитектура отделяет event layer от транспорта. Тогда сегодня события приходят через polling, а завтра через SSE или WebSocket без переписывания интерфейса.
- фиксируйте допущения до реализации;
- проверяйте решение на реальных данных и устройствах;
- сохраняйте наблюдаемость и возможность безопасного отката;
- усложняйте архитектуру только когда это подтверждает задача.