Реалтайм-паттерны: чат, нотификации, статусы, игры
Обзор задач, которые решают через WebSocket, и их особенностей.
Реалтайм-паттерн — типовая задача с живыми данными и характерным способом её решения через постоянный канал.
Зачем смотреть на паттерны
Технология одна, но задачи разные, и у каждой свои требования к частоте, надёжности и порядку сообщений. Понимание паттерна подсказывает, что важно: где нужна гарантированная доставка, где допустима потеря, где критичен порядок.
Шесть типовых паттернов
| Паттерн | Что течёт | Особенность |
| Чат | сообщения туда-сюда | важен порядок, нужна история |
| Нотификации | сервер → клиент | часто хватило бы SSE |
| Онлайн-статус | presence-события | «бесплатен» при живом сокете |
| Совместное редактирование | мелкие правки | нужен порядок и слияние конфликтов |
| Игры | координаты/действия | низкая задержка важнее надёжности |
| Тикер цен | поток обновлений | можно терять промежуточные значения |
Разные требования — разные решения
В чате потеря сообщения недопустима — нужна история и подтверждения. В игре наоборот: устаревшая координата бесполезна, и потерять её можно — главное низкая задержка. В тикере цен достаточно последнего значения, промежуточные можно отбрасывать (это называют «conflation»). Совместное редактирование — самое сложное: правки от разных людей надо корректно слить, для этого есть отдельные алгоритмы (OT, CRDT).
Как работает под капотом
Многие паттерны строятся на той же связке «комнаты + broadcast + протокол событий», что мы уже видели. Меняются детали: для нотификаций часто достаточно одностороннего SSE; для игр сообщения шлют десятки раз в секунду и иногда поверх UDP/WebRTC ради задержки; для редактирования каждое сообщение — небольшая дельта изменения, а сервер следит за их порядком. То есть выбор паттерна влияет на протокол сообщений и требования к инфраструктуре.
Частые ошибки
- Брать WebSocket там, где хватит SSE. Для чистых нотификаций двусторонний канал избыточен.
- Требовать гарантированной доставки в игре. Это раздувает задержку; иногда потеря лучше задержки.
- Делать совместное редактирование «в лоб». Без OT/CRDT правки будут затирать друг друга.
Итоги
- WebSocket решает много задач, но у каждой свои требования к порядку, частоте и надёжности.
- Чату нужна история и порядок; игре — задержка; тикеру достаточно последнего значения.
- Совместное редактирование требует алгоритмов слияния (OT/CRDT).
- Иногда вместо WebSocket уместнее SSE или WebRTC — выбирайте под паттерн.