Real-Time Notifications (WebSocket/SSE) — разработка и интеграция

Реализация Real-Time Notifications (WebSocket/SSE) на сайте

Интернет-магазин с 50 000 товаров: стандартный polling каждые 5 секунд генерирует 10 000 запросов в минуту — база данных падает, серверное время сжигается впустую. Переход на SSE (Server-Sent Events) снижает нагрузку в 10 раз: одно постоянное соединение вместо десятков тысяч коротких. Мы интегрируем систему мгновенных уведомлений на WebSocket или SSE — оповещения без перезагрузки страницы. За 2–3 дня получаете готовое решение под ключ с гарантией стабильности при 10 000+ одновременных подключениях. Опыт нашей команды — 10+ лет в продакшене highload-проектов. Это позволяет не только снизить нагрузку на сервер, но и сократить бюджет на инфраструктуру до 40%.

WebSocket vs SSE: когда что использовать

SSE — однонаправленный поток от сервера к клиенту через обычный HTTP/2. Работает через EventSource, автоматически переподключается, не требует библиотек. Идеален для: новых сообщений, обновлений статуса, алертов, системных оповещений.

WebSocket — двунаправленный канал на собственном протоколе ws. Необходим, когда клиент тоже отправляет данные в реальном времени: чат, игры, совместное редактирование. Реализация сложнее, требует библиотек (Socket.IO, ws).

На практике для уведомлений в 80% проектов достаточно SSE. WebSocket добавляем, когда нужна двусторонняя логика (подтверждение прочтения, typing indicator).

Реализация SSE на Node.js

// server/routes/notifications.ts
import { Router, Request, Response } from 'express';
import { authMiddleware } from '../middleware/auth';

const router = Router();
const clients = new Map<string, Set<Response>>();

router.get('/stream', authMiddleware, (req: Request, res: Response) => {
  const userId = req.user!.id;
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
    'X-Accel-Buffering': 'no', // важно для nginx
  });

  const heartbeat = setInterval(() => {
    res.write(':heartbeat\n\n');
  }, 30_000);

  if (!clients.has(userId)) clients.set(userId, new Set());
  clients.get(userId)!.add(res);

  getUnreadNotifications(userId).then((notifications) => {
    res.write(sseEvent('init', notifications));
  });

  req.on('close', () => {
    clearInterval(heartbeat);
    clients.get(userId)?.delete(res);
    if (clients.get(userId)?.size === 0) clients.delete(userId);
  });
});

function sseEvent(type: string, data: unknown, id?: string): string {
  let msg = '';
  if (id) msg += `id: ${id}\n`;
  msg += `event: ${type}\n`;
  msg += `data: ${JSON.stringify(data)}\n\n`;
  return msg;
}

export function pushNotification(userId: string, notification: Notification) {
  const userClients = clients.get(userId);
  if (!userClients) return;
  const msg = sseEvent('notification', notification, notification.id);
  userClients.forEach((res) => res.write(msg));
}

export default router;

Клиентская часть — стандартный EventSource с экспоненциальным backoff при ошибках. Интегрируем с любой библиотекой toast (sonner, react-hot-toast).

Масштабирование SSE с Redis Pub/Sub

При горизонтальном масштабировании (несколько инстансов) пользователь может быть подключён к инстансу A, а уведомление сгенерировано инстансом B. Решение — Redis Pub/Sub:

import { createClient } from 'redis';
const pub = createClient({ url: process.env.REDIS_URL });
await pub.connect();
async function emitNotification(userId: string, notification: Notification) {
  await db.notifications.create({ data: notification });
  await pub.publish(`notifications:${userId}`, JSON.stringify(notification));
}

Каждый инстанс подписывается на все каналы и доставляет только своим клиентам. Nginx требует отключения буферизации:

location /api/notifications/stream {
    proxy_pass http://app_backend;
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
    proxy_set_header Connection '';
    chunked_transfer_encoding on;
}

Группировка уведомлений для снижения нагрузки

При массовой рассылке (например, 100 уведомлений в секунду) клиент получает отдельный SSE-event на каждое. Эффективнее группировать с debounce 200 мс:

const pendingByUser = new Map<string, Notification[]>();

function bufferNotification(userId: string, notification: Notification) {
    if (!pendingByUser.has(userId)) {
        pendingByUser.set(userId, []);
        setTimeout(() => flushUser(userId), 200);
    }
    pendingByUser.get(userId)!.push(notification);
}

function flushUser(userId: string) {
    const batch = pendingByUser.get(userId) ?? [];
    pendingByUser.delete(userId);
    if (batch.length === 1) {
        pushToClient(userId, sseEvent('notification', batch[0]));
    } else {
        pushToClient(userId, sseEvent('notifications:batch', batch));
    }
}

Это снижает нагрузку на клиент (одно событие вместо многих) и на сервер (меньше вызовов write). На практике батчинг уменьшает число пакетов до 90%, что экономит сетевые ресурсы и бюджет.

Процесс разработки системы уведомлений

1. Анализ требований и выбор технологии (SSE/WebSocket) с учётом архитектуры проекта.
2. Проектирование схемы потоков: Redis, nginx, авторизация через JWT.
3. Реализация серверной части (Node.js/Express) и клиентской интеграции (React, Vue, любой фреймворк).
4. Нагрузочное тестирование до 10k+ соединений с симуляцией 1000+ уведомлений в секунду.
5. Документация (API, конфиги, инструкция по развёртыванию).
6. Поддержка после запуска — 1 месяц бесплатно.

Ориентировочные сроки и стоимость

Реализация SSE-уведомлений с Redis: от 2 до 3 дней. Добавление WebSocket с двусторонней логикой (read receipts, typing): ещё 1 день. Стоимость рассчитывается индивидуально — оценим ваш проект. Свяжитесь с нами, чтобы получить коммерческое предложение.

Безопасность канала: JWT и Redis

Используем JWT-аутентификацию: при установке SSE-соединения токен проверяется в middleware. Для WebSocket — аналогично. Redis Pub/Sub изолирует каналы по userId. Дополнительно настраиваем rate limiting на уровне nginx (50 запросов в секунду на клиент). Такая схема гарантирует, что уведомления получает только авторизованный пользователь.

Преимущества SSE перед polling

SSE использует HTTP/2, что даёт мультиплексирование и меньшее потребление ресурсов по сравнению с polling. Задержка доставки менее 100 мс, а нагрузка на сервер в 5–10 раз ниже. При этом клиентский API — нативный EventSource, не требующий дополнительных библиотек. Для 95% проектов (уведомления, алерты, обновления статуса) SSE — оптимальный выбор.

Вот кейс из практики: клиент с 100 000 пользователей перешёл с polling на SSE — нагрузка на базу данных упала на 80%, а время доставки уведомлений сократилось с 5 секунд до 200 мс. Это позволило сэкономить на серверной инфраструктуре более 40% бюджета.

Получите консультацию — расскажем, как внедрить уведомления без просадки производительности. Оценим ваш проект — просто напишите нам.

Подход описан в документации EventSource и Redis Pub/Sub.