skip to content

In Laravel, what is the difference between ShouldBroadcast and ShouldBroadcastNow, and when would you pick each for an auction's bid updates?

level: middleimportance: should knowfreq 40%

answer

  1. one queues, one does not
  2. Now extends ShouldBroadcast
  3. latency versus request time
  4. broadcastQueue() or #[Queue]
  5. ShouldRescue reports instead of throwing

basics

~20 s

ShouldBroadcast sends the event through a queued job, so a worker delivers it later and the request stays fast. ShouldBroadcastNow extends it and sends immediately inside the current process, adding the broadcaster call to the request but needing no worker.

solid answer

~40 s

With `ShouldBroadcast`, dispatching the event makes the broadcast manager push a `BroadcastEvent` job onto the queue; a worker later calls the driver, so delivery depends on worker health and queue backlog. `ShouldBroadcastNow` extends `ShouldBroadcast`, and the manager runs that job with `dispatchNow()` in the current process: no worker, lower latency, but the HTTP call to the WebSocket server happens inside the request and its failure surfaces there. For bid updates, queue them with `ShouldBroadcast` on a dedicated, fast queue (`broadcastQueue()` or `#[Queue('broadcasts')]`) when the request must stay quick; choose `ShouldBroadcastNow` when the bid must appear at once and a busy queue would make the price shown stale. `ShouldRescue` reports errors from pushing the job, or from the immediate send, instead of failing the request.

code

php · 20 lines
php
<?php

namespace App\Events;

use Illuminate\Broadcasting\Channel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcastNow;
use Illuminate\Contracts\Broadcasting\ShouldRescue;
use Illuminate\Foundation\Events\Dispatchable;

class HighestBidChanged implements ShouldBroadcastNow, ShouldRescue
{
    use Dispatchable;

    public function __construct(public int $auctionId, public int $amountCents) {}

    public function broadcastOn(): Channel
    {
        return new Channel('auctions.'.$this->auctionId);
    }
}

go deeper

for a junior

Recall that ShouldBroadcast queues the broadcast and ShouldBroadcastNow sends it immediately without a worker.

for a middle

Explain how the broadcast manager treats the two interfaces, how a queued broadcast picks its queue and connection, and what ShouldRescue covers.

for a senior

Weigh request latency against delivery freshness per event, isolate broadcast queues, and handle transaction timing and WebSocket outages.

for a principal

Decide which realtime updates are product-critical enough to couple to request latency, and how the platform degrades when the WebSocket tier fails.

## Two interfaces, one pipeline Both interfaces live in `Illuminate\Contracts\Broadcasting`. When an event that implements either is dispatched, the event dispatcher hands it to the **broadcast manager**, which wraps it in a `BroadcastEvent` job. The difference is only what happens to that job: | | `ShouldBroadcast` | `ShouldBroadcastNow` | |---|---|---| | How the job runs | pushed onto a queue | run with `dispatchNow()` in the current process | | Needs a queue worker | yes | no | | Adds time to the request | only the queue push | the full call to the broadcast driver | | Latency to the browser | queue wait plus processing | immediate | | Where send failures appear | in the worker, as a failed job | in the request that dispatched it | `ShouldBroadcastNow` extends `ShouldBroadcast`, so everything else — `broadcastOn()`, `broadcastWith()`, `broadcastAs()`, `broadcastWhen()` — works the same. ## Choosing the queue for queued broadcasts A queued broadcast goes to the default queue of the default connection unless told otherwise. The broadcast manager checks, in order: 1. a `broadcastQueue()` method on the event 2. a `broadcastQueue` or `queue` property 3. the `#[Queue]` attribute (Laravel 13) or a queue route registered for the class The connection comes from a `connection` property or the `#[Connection]` attribute. Putting broadcasts on their own queue keeps a pile of slow jobs, such as report exports, from delaying live price updates. ## Deciding for bid updates An auction page shows the current highest bid. The trade-off is: - **Queued (`ShouldBroadcast`)** — the bid request returns as soon as the job is pushed. If workers are healthy and the broadcast queue is short, the delay is small. If workers are down or backed up, bidders see stale prices, which in an auction's final seconds changes behaviour. - **Immediate (`ShouldBroadcastNow`)** — bidders see the new price as soon as the bid is saved, independent of queue health. The price is an HTTP call from the web process to the WebSocket server on every bid; if that server is slow or down, the bid request slows or fails. A common split is to broadcast the price with `ShouldBroadcastNow` and keep secondary events (activity feed entries, watcher counts) on `ShouldBroadcast`. ## Protecting the request Because a broadcast is usually supplementary, Laravel offers `Illuminate\Contracts\Broadcasting\ShouldRescue`. On an event that implements it, the broadcast manager runs its own step inside the `rescue()` helper: - for `ShouldBroadcast`, the step is **pushing the job**, so a queue backend outage is reported instead of failing the request - for `ShouldBroadcastNow`, the step is **the send itself**, so a WebSocket outage does not turn a successful bid into an error page An error in a queued broadcast's later send inside the worker is not covered by this; the queue treats it as a failed job. ## Timing against transactions An event dispatched inside `DB::transaction()` is broadcast when dispatched. With `ShouldBroadcastNow` that can publish a bid that is later rolled back; with `ShouldBroadcast` a fast worker can broadcast it before the commit. Adding `ShouldDispatchAfterCommit` to the event delays the whole dispatch, broadcasting included, until the outermost transaction commits. ## A quick decision checklist 1. Does the user who triggered the event need to see the broadcast before anything else happens? If so, consider `ShouldBroadcastNow`. 2. Is the event high-volume, where an extra call per request would add up? Queue it. 3. Would a WebSocket outage be acceptable to hide from the user? Add `ShouldRescue`. 4. Is the event dispatched inside a transaction? Add `ShouldDispatchAfterCommit`. 5. Does it share a queue with slow jobs? Give broadcasts their own queue. ## Other ways to send immediately - `Broadcast::on('auctions.42')->as('BidPlaced')->with($data)->sendNow()` sends an **anonymous event** at once, while `send()` queues it - `broadcast(new BidPlaced($bid))` goes through the same dispatcher and honours whichever interface the event implements ## Summary Queue broadcasts by default so the request stays fast, give them a dedicated queue, and switch to `ShouldBroadcastNow` only for the few events whose freshness matters more than the extra work in the request.

  • Can an event decide at runtime whether to broadcast at all?
    Yes. A `broadcastWhen()` method returning `false` makes the dispatcher skip broadcasting for that dispatch, for example only when the bid meets the reserve price. Ordinary listeners of the event still run.
  • What does ShouldRescue change when the WebSocket server is down?
    For a `ShouldBroadcastNow` event, the send runs inside Laravel's `rescue()` helper, so the error is reported to the exception handler and swallowed, and the bid request carries on. For a queued `ShouldBroadcast` event it only protects the push onto the queue; the worker's later send fails as a normal job.

saying these in an interview costs you the question

  • ShouldBroadcastNow still needs a queue worker, it just jumps the queue.
  • ShouldBroadcast sends the event inside the request and only logs it later.
  • Switching to ShouldBroadcastNow requires rewriting broadcastOn() and the payload.
  • A broadcast failure with ShouldBroadcastNow can never affect the HTTP response.