Broadcast

A broadcast is the single message a publisher sends to a real-time channel. The publisher emits one broadcast. The service receives one broadcast. Whatever happens after that (delivery to one subscriber, one thousand, or one million) is fan-out, not additional broadcasts.

Why it matters

The broadcast versus delivered-copy distinction is the single most consequential framing question in real-time pricing. The publisher's code does the same work regardless of subscriber count: one event dispatch, one serialized payload, one outbound HTTP request to the service. The service's work scales with subscribers. Pricing models that bill at the broadcast layer charge for the publisher's work. Pricing models that bill at the delivery layer charge for the service's work, multiplied by audience.

Modeling a real-time bill correctly starts with deciding which unit the service charges for. A workload with 100 broadcasts per minute against a 10,000-subscriber channel is 100 broadcasts under one model and 1,000,100 messages under the other. The protocol on the wire is identical.

How it works

A broadcast travels along a fixed path. The publisher's application code constructs an event (a name and a payload). A server-side SDK signs an HTTP request to the WebSocket service's REST API or pushes an event frame over an authenticated server-to-server WebSocket. The service receives the broadcast, looks up the channel's subscriber set, and writes a delivery frame to each connected subscriber.

A minimal Laravel broadcast:

class OrderShipped implements ShouldBroadcast
{
    public function __construct(public Order $order) {}

    public function broadcastOn(): Channel
    {
        return new PrivateChannel('user-'.$this->order->user_id);
    }
}

OrderShipped::dispatch($order);

That dispatch produces one broadcast. The service then fans it out to every active subscriber of private-user-42 over the Pusher protocol.

For public channels the same pattern applies without an auth route. For private channels the subscriber went through channel auth before joining; the broadcast itself does not re-check auth.

Related terms

• Fan-out is what happens to a broadcast after the service receives it.
• Fan-out tax is the surcharge applied when a service bills delivered copies instead of broadcasts.
• Pusher protocol defines the event frame format a broadcast becomes on the wire.

See also

• /compare/pusher-vs-vask for the broadcast-versus-message billing comparison.
• /learn/websockets-in-laravel for the Laravel broadcasting stack end to end.