How does real-time broadcasting work in Laravel?

Question

Accepted Answer

Laravel **broadcasting** enables **real-time** features (live notifications, chat, live updates) by pushing server-side events to the browser over WebSockets. It works by broadcasting Laravel events over a WebSocket connection, which JavaScript clients subscribe to and react to — bridging your backend events to the frontend in real time.

## The architecture

```text
Server event (e.g. MessageSent) → broadcast over a WebSocket channel →
  client JS (Laravel Echo) listening on that channel receives it → updates the UI live.

WebSocket server options:
  ✓ Laravel Reverb (first-party, self-hosted WebSocket server)
  ✓ Pusher (hosted service)
  ✓ Soketi (open-source, self-hosted)
```

## Broadcasting an event from the server

```php
<?php
class MessageSent implements ShouldBroadcast {       // mark the event to broadcast
    public function __construct(public Message $message) {}

public function broadcastOn(): Channel {
        return new PrivateChannel('chat.' . $this->message->room_id);   // the channel
    }
}

// dispatch it — it's sent to subscribed clients over WebSockets
MessageSent::dispatch($message);
```

An event implementing `ShouldBroadcast` is pushed over a WebSocket channel when dispatched. `broadcastOn()` defines which channel — public, **private** (auth-required), or presence (who's online).

## Listening on the client (Laravel Echo)

```js
// Laravel Echo — the JS library that subscribes to channels
Echo.private(`chat.${roomId}`)
    .listen('MessageSent', (e) => {
        addMessageToUI(e.message);     // react in real time when the event arrives
    });

// presence channels — track who's online
Echo.join(`room.${roomId}`)
    .here(users => ...)        // currently present users
    .joining(user => ...).leaving(user => ...);
```

The client uses **Laravel Echo** to subscribe to channels and run code when events arrive — updating the UI live without polling.

## Channel types and auth

```text
Public channel   → anyone can listen
Private channel  → requires authorization (defined in channels.php) — for user-specific data
Presence channel → private + tracks who's currently subscribed (online users)
```

## Why it matters

Real-time broadcasting is how Laravel implements **live, interactive features** — instant notifications, chat, live dashboards, collaborative updates, presence (who's online) — that the traditional request-response model can't provide (the server can push to clients, not just respond to requests).

Understanding it is valuable for building modern interactive applications that users increasingly expect.

The elegance of Laravel's approach is that it **bridges your existing backend events to the frontend in real time**: you mark an event as `ShouldBroadcast`, dispatch it as usual, and it's pushed over WebSockets to subscribed clients — so real-time features integrate naturally with your normal event-driven Laravel code.

On the client, **Laravel Echo** subscribes to channels and reacts to events, updating the UI live without inefficient polling.

Understanding the architecture (events broadcast over WebSocket channels, Echo on the client), the WebSocket server options (the first-party **Reverb**, hosted **Pusher**, or self-hosted Soketi), and the **channel types** (public, private with authorization for user-specific data, and presence for tracking online users) is important senior-level knowledge for building real-time features.

Since live, interactive experiences are increasingly expected in modern applications, and since Laravel provides an elegant system that connects backend events to real-time frontend updates, knowing how broadcasting works is valuable for building the responsive, real-time features (chat, notifications, live updates, presence) that distinguish modern, engaging applications — an increasingly relevant capability in contemporary web development.