Centrifugo — сильное решение для real-time систем. Особенно когда нужен отдельный WebSocket-слой, приватные каналы, публикация событий из backend-а, масштабирование и независимость от конкретного фреймворка.

Но Centrifugo не единственный вариант. И точно не всегда лучший.

В Laravel-проектах можно использовать Reverb, Pusher Channels, Ably, Socket.IO, Server-Sent Events, polling, long polling и разные внутренние брокеры сообщений. Иногда Centrifugo будет правильным выбором. Иногда он окажется избыточным. Иногда, как ни странно, обычный HTTP-запрос раз в 15 секунд будет дешевле и надёжнее.

В этой статье разберём альтернативы Centrifugo для Laravel: где что выбирать, какие есть плюсы и минусы, когда WebSocket оправдан, а когда real-time архитектура становится дорогим украшением.

Какие есть варианты?

Если нужно быстро выбрать направление:

• Polling — если обновления редкие и задержка не критична.

• SSE — если нужен простой поток событий только от сервера к клиенту.

• Laravel Reverb — если проект Laravel-first и нужна нативная интеграция с Broadcasting.

• Pusher — если нужен быстрый managed real-time без своей инфраструктуры.

• Ably — если нужен managed real-time с сильной платформой и SLA.

• Socket.IO — если realtime-слой уже живёт в Node.js или нужна богатая двусторонняя интерактивность.

• Centrifugo — если нужен отдельный self-hosted realtime gateway, независимый от Laravel.

Главная мысль:

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

Какие задачи решает real-time слой

Перед выбором технологии нужно понять, что именно должна делать система.

Real-time слой может решать разные задачи:

• доставлять уведомления пользователю;

• обновлять статусы заказов, платежей или задач;

• показывать live-дашборд;

• обновлять stream-виджеты;

• поддерживать чат;

• показывать presence: кто онлайн;

• обновлять админские панели без перезагрузки;

• доставлять события в интерфейс с минимальной задержкой;

• восстанавливать состояние после потери соединения.

И это разные уровни сложности.

Обновить счётчик уведомлений раз в минуту — одно.
Сделать чат, live support, stream overlay или финансовый realtime dashboard — другое.

Вариант 1. Polling

Polling — это обычный периодический HTTP-запрос.

Например frontend раз в 10 секунд спрашивает backend:

• Есть ли новые уведомления?

• Изменился ли статус заказа?

• Готов ли отчёт?

Пример:

setInterval(async function () {
    const response = await fetch('/api/notifications/count', {
        credentials: 'include',
        headers: {
            Accept: 'application/json',
        },
    });

    const data = await response.json();

    updateNotificationsCounter(data.count);
}, 10000);

Просто. Скучно. Работает.

И в этом нет ничего плохого.

Когда выбирать polling

Polling подходит, если:

• данные обновляются редко;

• задержка 5–30 секунд допустима;

• пользователей немного;

• нет сложных каналов и подписок;

• real-time не является ключевой частью продукта;

• команда не хочет поддерживать отдельный WebSocket-сервис.

Примеры:

• статус генерации отчёта;

• редкое обновление счётчика;

• проверка готовности файла;

• простая админская панель;

• личный кабинет без критичных live-событий.

Плюсы polling

• очень просто реализовать;

• понятно любому backend-разработчику;

• легко дебажить;

• не нужен WebSocket;

• не нужен отдельный сервис;

• работает почти в любой инфраструктуре;

• нет проблем с token refresh WebSocket-соединения.

Минусы polling

• лишняя нагрузка при большом количестве клиентов;

• есть задержка обновления;

• плохо подходит для частых событий;

• не подходит для чатов и live-интерфейсов;

• много пустых запросов, если данные редко меняются.

Вывод по polling

Polling — нормальное решение, если бизнесу не нужен настоящий real-time.

Вариант 2. Long polling

Long polling — промежуточный вариант между polling и WebSocket.

Клиент отправляет HTTP-запрос, сервер держит его открытым до появления события или до timeout. После ответа клиент сразу открывает новый запрос.

Схема:

• Frontend → HTTP request → Backend ждёт событие

• Backend → response при событии или timeout

• Frontend → сразу новый request

Long polling можно рассматривать, если:

• WebSocket недоступен или нежелателен;

• нужны более быстрые обновления, чем polling;

• событий немного;

• инфраструктура плохо поддерживает WebSocket;

• нужен временный компромисс.

Плюсы long polling

• работает поверх HTTP;

• меньше пустых запросов, чем у polling;

• может быть проще WebSocket в старой инфраструктуре.

Минусы long polling

• сложнее обычного polling;

• хуже WebSocket для частых событий;

• держит открытые HTTP-соединения;

• требует аккуратной настройки timeout;

• плохо масштабируется без продуманной архитектуры.

Вывод по long polling

Long polling — компромисс. Иногда полезный, но чаще это временная ступень между обычным polling и полноценным realtime-слоем.

Вариант 3. Server-Sent Events

Server-Sent Events — это однонаправленная доставка событий от сервера к браузеру поверх HTTP. В браузере для этого используется EventSource: клиент открывает постоянное HTTP-соединение, а сервер отправляет события в формате text/event-stream. MDN описывает EventSource как интерфейс для server-sent events, при котором соединение остаётся открытым до закрытия.  

Пример frontend-кода:

const events = new EventSource('/api/events');

events.addEventListener('message', function (event) {
    const payload = JSON.parse(event.data);

    handleEvent(payload);
});

Когда выбирать SSE

SSE подходит, если:

• нужны события только server → client;

• клиенту не нужно отправлять сообщения по тому же соединению;

• сценарии простые;

• нужно обновлять статусы, прогресс, уведомления, live-ленту;

• WebSocket выглядит избыточно.

Примеры:

• прогресс выполнения задачи;

• обновление статуса импорта;

• уведомления;

• live feed;

• простые dashboard-обновления.

Плюсы SSE

• проще WebSocket;

• работает поверх HTTP;

• нативно поддерживается браузером;

• хорошо подходит для server-to-client событий;

• понятная модель доставки.

Минусы SSE

• однонаправленная связь;

• не подходит для полноценного чата;

• сложнее делать presence и приватные подписки;

• нужны корректные настройки proxy и timeout;

• не всегда удобно масштабировать в PHP-only окружении.

Вывод по SSE

SSE — хороший выбор, если нужен простой поток обновлений от сервера к клиенту. Если frontend не должен активно отправлять realtime-сообщения обратно, SSE часто проще WebSocket.

Вариант 4. Laravel Reverb

Laravel Reverb — first-party WebSocket server для Laravel-приложений. Он работает внутри Laravel-экосистемы и интегрируется с Laravel Broadcasting и Laravel Echo. В официальной документации Laravel среди broadcast drivers указаны Reverb, Pusher Channels, Ably и log driver для локальной разработки.  

Для Laravel-команды это самый естественный кандидат после обычного polling.

Когда выбирать Reverb

Reverb подходит, если:

• проект полностью или почти полностью на Laravel;

• нужна нативная интеграция с Laravel Broadcasting;

• команда использует Laravel Echo;

• нет отдельного multi-language realtime слоя;

• нужен self-hosted WebSocket без SaaS;

• нагрузка умеренная или предсказуемая;

• команда хочет меньше интеграционного кода.

Плюсы Reverb

• официальное Laravel-решение;

• хорошая интеграция с Broadcasting;

• удобный developer experience;

• понятно Laravel-разработчикам;

• не нужен внешний SaaS;

• не нужен отдельный Go/Node realtime service;

• можно быстрее стартовать внутри Laravel-проекта.

Минусы Reverb

• привязка к Laravel-экосистеме;

• хуже подходит как универсальный realtime gateway для разных языков;

• эксплуатационно это всё равно long-running процесс;

• нужны supervisor, мониторинг, логи, деплой;

• для сложных multi-service сценариев может быть менее гибким, чем Centrifugo.

Когда Reverb будет хорошим выбором

Например:

• личный кабинет Laravel SaaS;

• уведомления;

• статусы заказов;

• простые админские панели;

• умеренный real-time;

• одна Laravel-команда;

• один основной backend.

Когда Reverb может быть слабее

Если у вас:

• несколько backend-сервисов на разных языках;

• real-time должен быть отдельным инфраструктурным слоем;

• много независимых источников событий;

• нужна языковая независимость;

• сложная модель каналов вне Laravel.

Вывод по Reverb

Reverb — хороший выбор, если проект Laravel-first и real-time нужен как естественное продолжение Laravel Broadcasting. Для многих Laravel-проектов это будет проще, чем Centrifugo.

Вариант 5. Pusher Channels

Pusher Channels — managed real-time сервис. Laravel давно поддерживает Pusher-подобную модель broadcasting, а Laravel Echo умеет работать с Pusher Channels. Pusher также указан в официальной документации Laravel среди поддерживаемых broadcast drivers.  

Когда выбирать Pusher

Pusher подходит, если:

• нужно быстро запустить real-time;

• нет желания администрировать WebSocket-сервер;

• команда маленькая;

• нагрузка умеренная;

• бюджет позволяет SaaS;

• SLA и скорость запуска важнее полного контроля инфраструктуры.

Плюсы Pusher

• быстрый старт;

• минимум эксплуатации;

• хорошая интеграция с Laravel Echo;

• не нужно думать о WebSocket-серверах;

• не нужно отдельно настраивать scaling и monitoring сервера;

• удобно для MVP и коммерческих продуктов с бюджетом.

Минусы Pusher

• стоимость растёт с нагрузкой;

• vendor lock-in;

• ограничения тарифов;

• данные и инфраструктура уходят во внешний сервис;

• меньше контроля над внутренней механикой доставки.

Вывод по Pusher

Pusher хорош, когда скорость запуска и отсутствие инфраструктурной боли важнее полного контроля. Для MVP, малого SaaS или команды без DevOps-ресурса это может быть рациональнее self-hosted решения.

Вариант 6. Ably

Ably — managed real-time platform. Laravel поддерживает Ably как один из broadcasting drivers, а у Ably есть отдельная Laravel-интеграция для Pub/Sub.  

Когда выбирать Ably

Ably подходит, если:

• нужен managed real-time;

• важны SLA и глобальная доставка;

• нужны дополнительные возможности платформы;

• нет желания поддерживать self-hosted WebSocket;

• проект коммерческий;

• бюджет на инфраструктуру нормальный.

Плюсы Ably

• сильная managed-инфраструктура;

• меньше operational burden;

• подходит для распределённых сценариев;

• есть Laravel-интеграция;

• не нужно держать свой WebSocket-сервер.

Минусы Ably

• стоимость;

• vendor lock-in;

• зависимость от внешнего провайдера;

• может быть избыточен для простых проектов;

• часть решений придётся подстраивать под платформу.

Вывод по Ably

Ably стоит рассматривать, когда real-time — важная часть продукта, но команда не хочет или не может держать realtime-инфраструктуру сама.

Вариант 7. Socket.IO

Socket.IO — популярное решение из Node.js-мира для bidirectional и low-latency communication. Важно: Socket.IO не является чистой WebSocket-реализацией; официальная документация прямо указывает, что это отдельный протокол поверх WebSocket при возможности, с дополнительными механизмами и metadata.  

Socket.IO также умеет fallback на HTTP long-polling, если WebSocket-соединение недоступно.  

Когда выбирать Socket.IO

Socket.IO подходит, если:

• основной realtime gateway уже на Node.js;

• команда уверенно работает с Node.js;

• нужна богатая двусторонняя интерактивность;

• нужны комнаты, события, кастомная server-side realtime логика;

• делается чат, multiplayer, collaborative UI, live-интерфейс.

Плюсы Socket.IO

• зрелая экосистема;

• много примеров;

• удобная событийная модель;

• есть комнаты;

• есть fallback-механизмы;

• хорош для чатов и интерактивных приложений.

Минусы Socket.IO

• добавляет Node.js-инфраструктуру рядом с Laravel;

• не является Laravel-native решением;

• нужна отдельная интеграция авторизации;

• нужны отдельный деплой, логи, мониторинг;

• может быть избыточен, если нужно просто доставлять backend events в UI.

Вывод по Socket.IO

Socket.IO хорош, если у вас уже есть Node.js realtime слой или нужна сложная двусторонняя интерактивность. Для Laravel-only проекта он часто избыточен.

Вариант 8. Centrifugo

Centrifugo — open-source real-time messaging server. В официальной документации он описывается как сервер, который доставляет сообщения онлайн-пользователям через WebSocket, HTTP-streaming, SSE, WebTransport и другие транспорты; клиенты подписываются на каналы и получают публикации через одно соединение.  

Когда выбирать Centrifugo

Centrifugo подходит, если:

• нужен отдельный realtime слой;

• Laravel — не единственный backend;

• события публикуют разные сервисы;

• нужен self-hosted вариант;

• не хочется платить SaaS по мере роста нагрузки;

• нужны каналы, приватные подписки, presence, history;

• важна языковая независимость;

• real-time должен быть инфраструктурным компонентом, а не частью одного Laravel-приложения.

Плюсы Centrifugo

• open-source;

• language-agnostic;

• self-hosted;

• заточен под real-time messaging;

• поддерживает разные транспорты;

• хорошо подходит как отдельный realtime gateway;

• может обслуживать несколько backend-сервисов;

• отделяет Laravel business logic от WebSocket-соединений.

Минусы Centrifugo

• ещё один сервис в инфраструктуре;

• нужны деплой, конфигурация, мониторинг, логи;

• интеграция с Laravel менее “родная”, чем у Reverb;

• команде нужно понимать JWT, каналы, publish API, token refresh;

• ошибки эксплуатации становятся частью real-time системы.

Когда Centrifugo сильнее Reverb

Centrifugo выглядит сильнее, если:

• есть несколько backend-сервисов;

• часть системы не на Laravel;

• real-time должен пережить смену backend-фреймворка;

• нужен самостоятельный gateway;

• команда готова эксплуатировать отдельный сервис;

• нагрузка и каналы могут расти независимо от Laravel.

Когда Centrifugo избыточен

Centrifugo может быть лишним, если:

• проект маленький;

• событий мало;

• вся система — один Laravel backend;

• команда не хочет держать отдельный сервис;

• реального real-time почти нет;

• обновление раз в 10 секунд достаточно.

Вывод по Centrifugo

Centrifugo оправдан, когда real-time — отдельная инженерная задача. Если же real-time в проекте — это пара broadcast-событий внутри Laravel, Reverb может быть проще.

Таблица сравнения

Что выбрать для Laravel-проекта

Маленький Laravel-проект

Выбор:

Polling или Reverb

Если обновления редкие — polling.
Если нужен настоящий WebSocket внутри Laravel-экосистемы — Reverb.

Centrifugo здесь может быть избыточным.

Laravel SaaS с личным кабинетом

Выбор:

Reverb или Centrifugo

Reverb проще, если всё крутится вокруг Laravel.
Centrifugo сильнее, если real-time планируется как отдельный слой.

MVP

Выбор:

Pusher или Ably

Задача MVP — быстрее проверить продукт. Managed-сервис может быть дешевле, чем неделя настройки собственного real-time слоя.

Highload или multi-service система

Выбор:

Centrifugo

Особенно если события приходят из разных сервисов, а real-time должен быть независимым от Laravel.

Enterprise или sensitive data

Выбор:

Reverb или Centrifugo self-hosted

SaaS может не пройти по требованиям безопасности, compliance или внутренней инфраструктурной политики.

Чат или сложная интерактивность

Выбор:

Socket.IO, Centrifugo или специализированная realtime-платформа

Тут важно смотреть на требования: presence, history, rooms/channels, нагрузка, интеграции, модерация, доставка, offline-сценарии.

Вывод

У real-time решений нет универсального победителя.

Reverb хорош как естественный путь для Laravel-проекта.
Pusher и Ably хороши, когда важны скорость запуска и managed-инфраструктура.
Socket.IO хорош там, где нужен Node.js realtime.
SSE и polling хороши там, где WebSocket будет избыточен.
Centrifugo хорош там, где real-time должен быть отдельным, масштабируемым и независимым инфраструктурным слоем.

Главная ошибка — выбирать технологию по моде.

Правильный подход другой:

Сначала требования, потом архитектура, потом инструмент.

И если после анализа окажется, что задачу решает обычный polling — это нормальное инженерное решение. Настоящая зрелость не в том, чтобы использовать WebSocket везде, а в том, чтобы не тащить production-сложность туда, где она не нужна.

Что еще почитать?

Если вы разбираетесь с real-time архитектурой в Laravel, одной статьи обычно недостаточно. WebSocket — это не только подключение клиента, а целая цепочка решений: backend, каналы, токены, события, очереди, frontend, эксплуатация и выбор подходящего инструмента.

Эта статья — часть серии про real-time архитектуру на Laravel и Centrifugo.

•  Зачем нужен WebSocket в Laravel-приложении

•  Архитектура Laravel + Centrifugo: роли backend, WebSocket-сервера и frontend

•  Каналы и авторизация в Centrifugo

•  Публикация событий Laravel в Centrifugo

•  Frontend и эксплуатация Centrifugo JS client

•  Альтернативы Centrifugo: Laravel Reverb, Pusher, Ably, Socket.IO, SSE и polling

Что еще почитать?

• Centrifugo — официальная документация
  Базовая документация по Centrifugo: сервер, каналы, подключения, публикации и основные сценарии real-time messaging.

• Centrifuge JS client
  JavaScript-клиент для подключения браузера, Node.js или React Native к Centrifugo/Centrifuge-based серверу.

• Centrifugo Client SDK specification
  Описание поведения клиентских SDK: подключение, подписки, reconnect, token refresh и обработка состояний клиента.

• Laravel Broadcasting
  Официальная документация Laravel по broadcasting, Laravel Echo, channels, events и broadcast drivers.

• Laravel Reverb
  Официальная документация Laravel Reverb — first-party WebSocket-сервера для Laravel-приложений.

• Laravel Queues
  Документация по очередям Laravel: jobs, workers, retries, failed jobs и обработка фоновых задач.

• Laravel Events
  Документация по событиям Laravel: events, listeners, subscribers и асинхронная обработка.

• Laravel Echo
  Клиентская библиотека Laravel для подписки на broadcast-события во frontend-приложениях.

• Pusher Channels
  Документация managed real-time сервиса Pusher Channels.

• Ably Pub/Sub Channels
  Документация Ably по каналам, Pub/Sub и real-time messaging.

• Socket.IO
  Документация Socket.IO — библиотеки для bidirectional event-based communication между клиентом и сервером.

• MDN WebSocket API
  Базовое описание WebSocket API в браузере.

• MDN EventSource / Server-Sent Events
  Документация по Server-Sent Events и интерфейсу EventSource.