Reverb WebSocket dispatch console explained

The polling model that dominated 2010s cloud dispatch worked like this: the dispatcher's browser asked the server every 5-15 seconds whether anything had changed. The server responded with a snapshot of the current state. The dispatcher's console updated on receipt. This worked acceptably when fleet sizes ran 20-40 vehicles and live booking counts stayed under 10; it broke down structurally above that scale because the 15-second worst-case lag on visible state began to materially affect operating decisions.

The 2026 WebSocket model replaces request-response with persistent bidirectional connection. Server pushes state changes the moment they occur — driver location update, booking accept, flight delay ingest, dispatcher reassignment. The dispatcher console renders the change within 100-300ms of server emit, typically including the round-trip across the network. Sub-second is qualitatively different from 15-second; the dispatcher experience shifts from 'monitoring stale snapshots' to 'watching the operation happen'.

Reverb specifically is Laravel's first-party WebSocket server, released in 2024. It runs as a separate PHP process from the main Laravel application, handles connection lifecycle management cleanly, and integrates with Laravel's broadcasting events without external dependencies (no Pusher, no Ably, no third-party WebSocket vendor). For TaxiCloud, that means the WebSocket layer ships with the platform without external service dependencies — operationally simpler, no per-message billing, no third-party SLA dependency.

Event channels in the Reverb-powered console are scoped by tenant, base, and dispatcher role. A dispatcher in the Manchester base subscribes to the Manchester-base channel; events broadcast to other bases don't reach that dispatcher. Multi-base operators run separate channel scopes per base with a super-dispatcher channel for after-hours coordination. The scoping keeps console UX clean even for 5+ base operations.

Driver-location updates are the highest-volume event class. Drivers' apps push location updates every 5-15 seconds depending on shift state (faster during active trip, slower during idle). The console renders the updates as live vehicle position changes on the dispatcher's map; AI Copilot ingests the location stream for positioning recommendations; rider-side live tracking renders the same stream with selective driver-anonymisation for privacy.

Booking-state events broadcast on every meaningful state change: created, assigned, accepted, en-route to pickup, pickup completed, dropping off, completed. Each state change emits an event with full booking context; the dispatcher console renders the state transition with appropriate visual treatment; corporate-account dashboards (for the largest fleets) ingest the same stream for real-time visibility into pickup status.

AI Copilot recommendation events are emitted whenever Copilot identifies a positioning opportunity, a delay-response action, or a reassignment recommendation. The recommendations surface in the dispatcher console as gentle suggestions ('reassign driver 17 to airport pickup — 8 minute net improvement'); the dispatcher approves or rejects with a click. The accept/reject signal is fed back into Copilot's calibration pipeline.

Reliability considerations matter at scale. WebSocket connections can drop on network instability, browser tab background-throttling, or server-side maintenance. The console handles this with auto-reconnection logic, state-reconciliation on reconnect (pulls the latest snapshot to fill gaps), and dispatcher-visible connection-status indicator. The visible status indicator is itself an operational feature; dispatchers know immediately if they're watching stale state.

Comparing the Reverb console against polling-based competitors during evaluation is straightforward. Time how long it takes for a driver-app status change to appear in the dispatcher console. On Reverb, the change appears in 200-500ms typically. On polling-based platforms, the change appears in 5-15 seconds. The qualitative difference is obvious within the first minute of side-by-side testing.

Driver-app experience also benefits from WebSocket architecture. Push-notification latency on offer accept, booking cancellation, or dispatcher message drops from typical polling-platform 5-30 second latency to sub-second. The driver-side feel is the difference between 'app that occasionally surprises you' and 'app that feels responsive to what's actually happening'. Driver-NPS in TaxiCloud deployments typically runs 12-25 points above polling-platform comparables, attributable in part to this latency delta.

Rider-app live tracking also runs on the WebSocket stream. The driver position on the rider's tracking screen updates every few seconds with no jitter; the ETA recalc happens on the rider's screen within a second of any meaningful traffic change. Compared to polling-based tracking UX, the WebSocket UX feels like a different category of product.

The forward direction is structural integration of WebSocket events into corporate-account dashboards, accessibility-feature workflows, and multi-base coordination tooling. TaxiCloud's roadmap continues to expand the event surface — every operational signal that matters to a dispatcher, driver, rider, or corporate-account contact is moving into the real-time event stream. The architecture is the moat; competitor platforms running on 2010s-era polling won't close the gap without a structural rewrite.