---
title: Delivery Tracker
description: >-
  A real-time delivery-dispatch system that assigns orders to drivers based on distance, current load, and historical
  performance. PostGIS spatial queries, Socket.IO driver tracking, scoring-based assignment iterated with the dispatch
  team.
lang: en
source: https://jimrarras.com/en/projects/delivery-tracker/
fetched: '2026-09-19T05:53:17.505Z'
---

Lead Developer

A real-time delivery-dispatch system that assigns orders to drivers based on distance, current load, and historical performance. PostGIS spatial queries, Socket.IO driver tracking, scoring-based assignment iterated with the dispatch team.

## Stack
## The situation

A dispatch team coordinates drivers across a city. Orders arrive all day, and for each one somebody has to decide which driver takes it. I built a system, on my own, that makes that decision the moment the order lands. It is one team’s internal tool, with no public address.

## The dispatcher sees everybody

Every driver runs an app on their phone that streams their position continuously. The dispatcher no longer rings around asking where anyone is: they see all of them at once on the map, moving.

How it works

- **Two directions, kept apart:** Socket.IO holds separate channels for drivers, who push position up, and for dispatchers, who pull the live map down.
- **The map:** React 19 with TanStack Query for the data, Mapbox GL for rendering.
- **The core:** Fastify on Node 22, PostgreSQL with the PostGIS extension, Drizzle ORM on top.

## The assignment makes itself

When a new order comes in, the system picks the driver before anyone has time to look at the map. It works out who is near, who is free and who is performing well, and offers the order to one of them.

How it works

- **Why PostGIS and not application code:** haversine maths for every driver on every order intake would tank the request path. The database answers within-radius queries at index speed, under 100ms even with hundreds of drivers online.
- **What is computed spatially:** within-radius queries and route-distance approximations, both indexed.
- **The score:** a weighted formula combining straight-line distance, current active load, recent rating and acceptance rate.

## The closest driver was the wrong driver

The first version of the formula weighted distance heavily, as anyone would. Real-world testing with the dispatch team showed that current load matters more.

A driver one block away with three active orders is a worse choice than one a kilometre away with none.

I settled on a weighted blend that the team ran over past days of work before we went live, to see whether its picks agreed with theirs.

How it works

- **How it was validated:** the formula was run against past runs and compared with the assignments the team had actually made, before it went to production.
- **What changed:** the weight moved off distance and onto current load, with recent rating and acceptance rate acting as corrections.

## Links

## Related work

- Internal-only deployment, no public URL.

- TaskFlow: another realtime multi-tenant system, but task dispatch instead of delivery dispatch
- Komvos Connect: another Fastify + Drizzle + Socket.IO stack, but appointment booking instead of GIS-based dispatch