Sub-5s

location updates, down from minute-long lags

Logistics & Mobility case study

Dispatch and live tracking that hold up at rush hour

A last-mile operator whose tracking lagged and whose dispatch double-booked drivers got a rebuilt, real-time core.

Client
Transit Loop
Vertical
Logistics & Mobility
Role
Dispatch engine and live tracking rebuild
Year
2023

How it ran

From brief to outcome.

  1. 01

    Brief

    Make the map trustworthy at rush hour and stop assigning one driver two jobs. The peak is the whole point.

  2. 02

    Approach

    Profile under peak load, stream location updates, and rebuild matching so assignment is atomic.

  3. 03

    Build

    A streaming location pipeline, an atomic matching engine, a live dispatch board, and replay tooling for incidents.

  4. 04

    Launch

    Rolled out in one city at peak, watched the replay tooling confirm no double-bookings, then expanded.

  5. 05

    Outcome

    Tracking stayed within seconds of reality, double-booking stopped, and the support team got its peak hours back.

What changed

Before, and after.

Driver location lag at peak
BeforeUp to ~90s
AfterUnder 5s
Double-booked assignments
BeforeSeveral per peak
AfterNone recorded
Support calls during rush hour
BeforeHeavy
AfterMuch lighter

The work

The problem, and how we took it on.

The challenge

Transit Loop's map showed drivers minutes behind where they actually were, so dispatch and customers were working off stale positions. At rush hour the matching logic sometimes assigned two jobs to one driver, and the support team spent the peak untangling it by phone. The system was fine at low volume and unreliable exactly when it mattered.

Our approach

  • Profiled the system at peak first, because the problems only showed up under rush-hour load.
  • Moved location updates onto a streaming path so the map reflects where a driver is now, not a minute ago.
  • Rebuilt matching so a driver can't be assigned a second job while the first is still being confirmed.
  • Made the dispatch board reflect live state, so the team stops working from a snapshot that's already wrong.

What we built

  • A streaming location pipeline that keeps the map within a few seconds of reality.
  • A matching engine that locks a driver during assignment so double-booking can't happen.
  • A live dispatch board that shows real-time driver state and open jobs together.
  • Replay tooling so the team can see exactly what happened during a busy window.

The outcome

The map now matches what's happening on the road, so dispatch and customers stop chasing positions that already moved. Matching can't hand one driver two jobs anymore, which was the single biggest source of rush-hour chaos. The support team is no longer absorbing the peak by phone, and when something does go wrong, the replay tooling shows precisely what happened.

Built with

The stack on this project.

TypeScriptNode.jsReact NativePostgreSQLRedisKubernetesAWS

Where this fits

The services and industry behind it.

Straight answers

Questions about this build.

Why did the problems only appear at peak?

At low volume the old polling and matching logic kept up. Under rush-hour load, location updates queued behind each other and assignment races appeared. That's why we profiled at peak before changing anything.

Have a problem like Transit Loop’s?

Tell us what's slowing your product down. We reply to every serious enquiry within one business day.