The open ride moves with the car.
What did this project ship?
Open a live ride and leave it open. The status, the chauffeur’s pin, and the trail arrive as events. The page applies them in place.
- Live status
- Driver broadcast
- Trail inserts
- Stale pin
- Socket backup
- Open desk
- Industry
- Mobility
- Country
- India
- Scope
- Operations desk
01
The desk stays on the trip
The driver phone publishes driver_location on ride-updates for that ride, and the ride row changes as the shift moves through accept, arrive, start, and collect. The desk is subscribed to those changes. An operator watching one trip does not reload to see the car move.
02
Engineering challenges
The open ride is a live trip. Status, the pin, and the trail each arrive on their own channel. A page that fetched the row once is looking at a car that has already moved.
- 01The row moves while the page sits open
Accept, arrive, the OTP time, start, the actual drop, payment, the deviation agreement, and the call mask all land on the ride after the desk loaded it. An operator on the phone with a rider is then reading a status the shift has already left.
- 02Three places the car can be
The driver phone sends driver_location on the ride-updates channel. ride_location_history receives an insert for the saved trail. drivers.current_lat updates on the driver row. A map that paints only one of those shows a car with no line behind it, or a line whose end is minutes behind the car.
- 03A late event pulls the car backward
The broadcast and the driver-row update do not arrive in order. Apply an older timestamp on top of a newer one and the marker jumps back while someone is watching the Mumbai map.
- 04The socket drops mid-trip
The channel can disconnect while the chauffeur is still moving. If the only update path was that socket, the pin freezes until the page is reloaded. If the backup poll is as slow as a healthy connection, a dead socket and a live socket are equally late.
- 05A finished trip keeps the channel open
Completed and cancelled still have a trail, and the car is no longer moving. Leave the ride channel, the history subscription, and the location poll running and the desk keeps drawing points after the trip ended.
- 06Every open desk has to hear the same event
A booking pause and a new support ticket happen while other operators already have the desk open. If those land only on the next full load, the second desk still shows the city as open and the inbox as quiet.
03
How we solved them
The open ride subscribes. Status is a row change. The pin is the same broadcast the driver phone sends. The trail grows by insert. A poll is the backup when that socket is down.
- The ride row patches the open page
admin-ride-detail listens for an update on that ride. The event writes status, the step timestamps, payment, the actual drop, the deviation flag, and the call mask into the page already on screen. Earnings reload from that same event. The operator does not reload.
- The pin is the driver’s broadcast
The desk joins ride-updates for that ride and takes the driver_location event: latitude, longitude, heading, and the timestamp. A second channel listens for an update on that driver’s current position. Both write the same marker.
- The trail appends
admin-ride-location-history listens for an insert on that ride. A point whose id is already on the line is dropped. The rest are sorted onto the polyline, and the live pin is added at the end while the trip is still moving.
- An older fix is ignored
A location is applied only when its recorded time is at least as new as the one on screen. A broadcast that arrives late does not pull the car backward. A point older than the stale window is marked late, and the route treats it as not fresh.
- The poll depends on the socket
While the channel is subscribed, the ride and the pin use a slow backup read. When the subscription drops, that read tightens. On subscribe, the desk fetches once, so the gap while the socket was down is filled. Completed and cancelled stop the ride poll.
- Pause and the inbox are events too
booking_paused is a change on that settings row, applied on every open desk. A new support request, a status change on one, and a rider message each arrive on the support channel and update the badge in place.
04
System design
One channel name per live ride, shared with the driver phone. The durable status is the ride row. The moving pin is the broadcast. The list behind the detail is a separate, slower read.
- 01ride-updates is the shared channel
The driver phone keeps one channel open for that ride and sends driver_location, ride_status_changed, and stop_reached on it, including across a token refresh. The desk joins the same channel for the pin. Status on the desk comes from the ride row, so a missed broadcast does not leave the chip behind the database.
- 02Live means a set of statuses
The pin, the history channel, and the history poll run from accepted through collect_cash: arrived, the start photos, started, and the end photos. Completed and cancelled leave that set. Points recorded after the trip end stay off the driven line.
- 03The marker and the road are separate
The live coordinate is appended to the saved samples, then a street path is built for a one-way trip. The navigation route uses that pin only while the ride is live and the point is still fresh. A round trip does not build that driven street path.
- 04The rides list is not the ride channel
The open ride is event-driven. The rides table is a paged query with its own refetch. Opening a row is what starts admin-ride-detail, the history channel, and ride-updates. Closing the page removes those channels.
- 05Support and the pause sit on their own channels
admin-support-inbox listens to inserts and updates on support_requests, and to a rider insert on support_request_messages. admin-booking-paused listens to the booking_paused key. Neither waits on the ride channel.
- 06A disconnected desk still has a clock
isRealtimeConnected follows the subscription status. The backup interval is chosen from that flag. A stale check on a timer marks a pin whose last time is too old, so the route stops treating a frozen car as live.
05
What the desk includes
Leave a live ride open. The chip, the car, and the line change as the chauffeur moves. The inbox and the booking pause change the same way.
- 01The status chip
Requested becomes accepted, arrived, the photo steps, started, collect cash, then completed or cancelled, on the page that was already open. Payment, the masked numbers, and the actual drop update with that row.
- 02The car on the map
Leaflet draws the chauffeur from the live pin. The point goes stale if it stops arriving. Pickup, drop, and the actual stop stay on the same map.
- 03The line behind the car
The recorded trail lengthens as history inserts arrive. The timeline under the map follows those points. A one-way trip also draws the street path from the samples plus the live pin.
- 04The same channel as the driver phone
The pin is the driver_location event that phone already sends for the rider map. The desk is another listener on ride-updates. It does not ask the chauffeur’s app to publish a second stream.
- 05A ticket while the ride is open
A new support request and a rider reply raise the badge and the alert without leaving the ride. Complaints still have their own detail page.
- 06The city pause
Settings holds booking_paused. Flipping it updates every open desk. New bookings stop. Trips already accepted keep moving, and those rides stay on the live map.
06
What we built
We shipped the Sevenco operations desk on the same realtime channels as the driver app. The open ride patches from postgres changes and from the driver_location broadcast. A poll runs only as the backup, and it stops when the trip is completed or cancelled.
07
Runtime
Clocks from the live ride on the operations desk.
A pin older than this is marked late
Ride and pin read while the channel is up
Ride and pin read while the socket is down
History poll while the ride is live
Location points loaded for one ride
How often a stale pin is rechecked
Rides table refetched
Rides on a list page
08
What we delivered
- Sevenco operations desk
- Sign-in that requires profiles.role admin or super_admin
- Dashboard for all time, today, this week, and this month
- Rides list with status and search
- Live ride page: status, payment, and call mask patched from the ride row
- Driver pin from the driver_location broadcast on ride-updates
- Trail from ride_location_history inserts, drawn on Leaflet
- Drivers, pending verification, and driver detail
- Users and user detail
- Complaints
- User support inbox
- Notifications
- Coupons
- Payments
- Withdrawals, completed or rejected through admin_apply_payout_result
- Training videos, encoded in the browser when they exceed the storage cap
- Settings, including the booking pause
- Service regions and banners in development builds
09
Technology
- React
- TypeScript
- Supabase
- PostgreSQL
- Vite
- Leaflet
- TanStack Query
Live product
In production.
The desk runs against the same database as the Sevenco rider and driver apps.