A customer tracking an order wants to know when its status changes. An event organizer wants the standings to reflect the latest result. Neither particularly wants to refresh a page until something interesting happens.
Those are good reasons to consider real-time features in a Laravel application.1 The value is a useful change reaching the right person while it still matters.
Laravel Cloud introduced managed WebSockets powered by Laravel Reverb on November 13, 2025.2 Reverb itself arrived with Laravel 11 in 2024; the new development is the managed Cloud offering. It adds a hosting option for applications that need persistent connections between server and browser.
That infrastructure is useful. The more important design question comes first: which business event deserves an immediate update?
Match the connection to the job
A WebSocket keeps a connection open so the application can send updates to the browser. Polling has the browser ask for the latest information at intervals. Both approaches have a place.
Use polling when a little delay is comfortable
An account page showing a monthly usage total may work perfectly well with a normal page load or occasional refresh. A dashboard checked a few times a day may not need continuously updated data.
Polling can also be a reasonable choice for a modest application where updates are infrequent and a short delay is acceptable. Its requests still consume resources, so the interval and number of active users matter.
I would start by asking how stale the information can become before somebody makes a worse decision. “As live as possible” sounds lovely until every quiet browser tab starts behaving like a correspondent covering a national emergency.
Use push when people are waiting for the event
A live event board is a stronger candidate. Once a result is accepted, participants should see the updated standings without repeatedly checking.
Order preparation can be similar. Staff may need the next task to appear promptly, while a customer needs to know that collection is ready. These are different audiences for related events, and they may require different messages.
When off-the-shelf stops fitting, see how we approach custom development.
Managed Reverb handles part of the connection infrastructure. The application still needs to decide when an event is valid, who should receive it and how the interface should react. Real-time transport cannot make an unfinished business rule finished.
| Polling | Push (WebSockets) | |
|---|---|---|
| How it works | The browser asks for the latest information at intervals | The application keeps a connection open and sends updates as they happen |
| Suits | Infrequent updates where a short delay is acceptable, such as a monthly usage total | People waiting for an event, such as live standings or the next order to prepare |
| Watch for | Requests that still use resources even when nothing has changed | Accepted changes only, authorised channels and a plan for reconnection |
Make the live view trustworthy
The browser should present the system’s authoritative state. It should not become a competing version of the business record.
Publish a change after it is accepted
Imagine an event result that still needs an organizer’s approval. Broadcasting the provisional value as final could move several people up and down the leaderboard before the underlying decision is made.
The same issue applies to an order status. A request to mark an order ready should first pass the relevant checks and persist successfully. The live message then reflects that accepted change.
Where database transactions and queued broadcasts are involved, the implementation needs to coordinate them so an update does not announce information that later rolls back. Otherwise, the customer gets an exciting notification followed by an unexpectedly philosophical discussion about whether their order exists.
Treat reconnection as part of the feature
Phones switch networks. Laptops sleep. Venue Wi-Fi occasionally pursues a career in abstract performance.
A browser returning after a connection loss needs a way to retrieve the current state. Depending on the application, that may mean fetching a fresh snapshot or requesting changes since a known version. The interface should avoid presenting an old display as confidently live.
Repeated or out-of-order messages also deserve a plan. Stable event identifiers or record versions can help the application decide whether an update is new and relevant. The right approach depends on the workflow; the requirement is a coherent result after interruption.
Pairs well with A live leaderboard has to earn the word live.
Design for attention and appropriate access
Private information needs authorization at the subscription point and careful selection of what is broadcast. A customer should receive their own order updates. A public leaderboard should receive the fields intended for public display.
This matters even when the application interface already hides private records. Channel access and message contents need their own review.
The presentation deserves similar care. Updating an entire table whenever a minor value changes can disrupt reading or move the item someone was about to select. Consider a restrained indicator, a stable position or a clear invitation to refresh the changed section.
And give “live” a useful meaning. An indicator can show when the connection is unavailable or when data was last refreshed. Quiet honesty is more reassuring than a permanently green dot with a very relaxed relationship to reality.
For a Laravel project, I would prototype one important event through the complete journey: accepted change, authorized delivery, visible update and reconnection. Then evaluate whether the experience improves enough to justify expanding it.
The nicest real-time features often feel unremarkable. The order moves forward, the right person sees it, and nobody has to babysit the refresh button. Now that is Ayoba!