Guaranteed Journeys: Protecting Corporate Accounts with a LiveView Real-Time Dashboard

In the world of B2B ride-hailing, reliability is currency. Failing to assign a ride for a corporate client doesn’t just annoy a user—it jeopardizes entire enterprise contracts.

At Cabify, our operations team initially relied on a Looker Studio dashboard to manage these critical journeys. The result was frustration: data was stale due to polling, BigQuery costs were mounting, and agents were losing precious seconds waiting for refreshes while VIP clients waited for rides.

We needed a replacement that was real-time, cost-efficient, and reliable. We needed it immediately.

This talk dissects how a single backend developer replaced that legacy solution with a Phoenix LiveView dashboard in just two weeks, achieving a 99% assignment success rate.

Key Takeaways:

The “Build vs. Buy” Tipping Point: Learn how to identify when a generic BI tool (like Looker Studio) becomes a liability. We will show that when “Read-Only” analytics turn into “Read-Write” operations, moving to a custom LiveView app is not just faster—it’s cheaper and safer.

Velocity without Fragility: Discover how the LiveView architecture allowed a single backend developer to bypass the complexities of API design, state synchronization, and React/JSON glue code to ship a production-hardened internal product in just two weeks.

From Polling to Push: See the tangible architectural benefits of replacing expensive, laggy polling queries with real-time Phoenix PubSub streams, resulting in immediate data consistency for agents and reduced database load.

Target Audience:

This talk is designed for Engineering Managers and Technical Leads looking for high-ROI strategies to build internal tools with limited resources, as well as Backend Developers eager to leverage LiveView to deliver full-stack, real-time applications without the complexity of a separate frontend codebase.

Transcript

1. #ElixirConfEU Guaranteed Journeys: Protecting Corporate Accounts with a LiveView Real-Time Dashboard Gabriel Ortuño, Staff Engineer @ Cabify
2. The problem  "Missed flight" anxiety High-stakes travel where every minute counts.  Delayed pickups Presents a real risk for corporate riders and reputation.  Lack of guarantees Uncertainty in scheduled journeys damages trust.
3. The first prototype  Dashboard Monitoring Monitoring system based on a Looker Studio dashboard.  Real-time Oversight Allowed operations agents to oversee reservations in real-time.  Active Intervention If a journey flagged a potential delay, agents intervened.
4. Inserta una imagen en esta posición (Recursos en la pág 74 del template) But it has some limitations High Costs: Running frequent BigQuery refreshes significantly increased operational expenses. 4 Pull Based Architecture: The lack of real-time updates caused delays in identifying urgent issues. Fragmented Workflow: Agents had to switch to a separate tool (Remedios) to take action. Lack of Ownership: No assignment feature led to duplicate efforts on the same journey.
5. The Mission Build a scalable, real-time, operational dashboard
6. Strategic constraints & Scope Those trade-offs only make sense in context. This was not a generic “best stack” decision. It was a decision for a very specific product and operational environment. It was a bounded internal operational workflow, which allowed us to make pragmatic trade-offs. 6 ~90 Users ~30K Weekly journeys 2w Deadline 1 Backend Engineer
7. Inserta una imagen en esta posición (Recursos en la pág 74 del template) Inserta una imagen en esta posición (Recursos en la pág 74 del template) Inserta una imagen en esta posición (Recursos en la pág 74 del template) Why not a JS SPA What we wanted to optimize Reduce coordination overhead Avoid splitting the solution across backend and SPA layers. Reduce cognitive load Choose a model with fewer moving parts and less context switching. Reduce delivery risk Keep one engineer able to own the full flow end to end.
8. 8 Go + HTMX Strong team familiarity Existing Go knowledge reduced ramp-up time. Great runtime performance Efficient concurrency and predictable backend performance. Mature ecosystem Well-supported libraries, tooling, and practices. Simple server-driven UI HTMX enabled interactivity without a separate SPA. Coordination infrastructure Live updates across nodes likely needed Redis or similar. Integration code Real-time sync required more application glue code.
9. 9 Phoenix LiveView No custom API layer No separate frontend-backend boundary for this tool. Fast UI delivery LiveView and DaisyUI speed up implementation. Built-in clustering Cross-node updates worked with no extra infrastructure. Real-time updates Live changes propagated with little application glue. Per-user state Each operator kept isolated interactive state. End-to-end ownership One backend engineer could build the full flow.
10. The solution How the BEAM shaped our architecture
11. 11 Architecture: Data flow Message Queue LiveView (Per User Process) Event Handler Journeys Domain Database (Durable SoT) PubSub (Fast propagation) Consume event Process event Clustered Application Operator Persist Render state Broadcast Subscribe ETA Server Scheduled ETA Service Refresh
12. 1. Only manage journeys at risk Only model the high-risk window and keep LiveView state bounded. 4. Centralize ETA access and reuse results A singleton ETA manager reduced duplicated requests and reused cached responses across LiveViews. 12 Key architectural decisions 2. Durable truth, fast propagation Database as durable SoT, PubSub for fast propagation. 5. Let the platform absorb coordination and recovery Use supervision and clustering instead of custom recovery logic. 3. Push journey state changes, recompute ETA periodically Use push updates for journey state changes, and bounded recomputation for ETA-based signals. How we kept the system simple enough to ship and robust enough to run
13. The learnings Principles for making architecture decisions under constraints
14. Scope is often the best scalability strategy
15. Choose technology by the problems it removes
16. Architecture decisions are about cost curves, not preferences
17. Thanks Gabriel Ortuño, Staff Engineer @ Cabify