Case study · Backend

Durable planning pipeline and trusted commands

Implemented · tested (static) · multi-company · demo hosted

A trucking office needs one trustworthy record of trucks, drivers, loads and plans, even when several people work at once. RouteDawg's backend checks every change at a trusted boundary, makes retries safe for its core commands, and runs route planning in the background, with problems surfaced for attention instead of lost.

RouteDawg admin console, booking for the demo company: shipments with status, broker, lane, agreed rate, pickup time and crew.
Admin console: shipments
Actual application capture · RouteDawg web app (installable) · build bd55dc2b7 · demo company data

Overview

The system of record is Postgres 17 on Supabase, with more than 100 migrations and row-level security on all 70 public tables (119 policies); every row is keyed by company. Commands take one of two paths. Four Deno edge functions (truck commands, the worker, truck projection and load economics) handle transport and authentication only; services hold the business meaning, and repositories run SQL in one transaction.

Newer features call about 46 Postgres functions from the Next.js server, with their rules in SQL. One idempotency implementation serves the core command families (truck, driver, dispatch, booking and assignment): it serialises on the command id, checks digest, type and actor, and fails closed when evidence is missing, so a retry never applies twice and a rejected command leaves nothing behind.

Route planning is a durable asynchronous operation: a pg_cron job claims work every 15 seconds into an outbox, and a worker hands it to a Node planning host, which calls the Python engine of Route Optimizer, a separate system, through the versioned ro-planning-intent-v2 contract. Results become route plans, with explicit attention and quarantine paths.

The planning host runs a pinned, archived Route Optimizer build with a recorded rollback; cross-system tests run against fixed Route Optimizer checkouts. Multi-company isolation is in place and a demo is hosted.

Visual evidence

Installable web apps
Admin console
Manager app
Driver app
Next.js serversession tokens in httpOnly cookies, not browser storage
Two command paths
Core commands
4 Deno edge functionstransport and authentication only
Servicesbusiness meaning
RepositoriesSQL in one transaction

Idempotent for truck, driver, dispatch, booking and assignment commands: serialised on the command id, checked by digest, type and actor, failing closed.

Newer features
≈46 Postgres functionscalled from the Next.js server; rules in SQL
System of record and planning
Postgres 17 on Supabase100+ migrations · RLS on 70 of 70 public tables (119 policies) · every row keyed by company
Outbox and worker
Node planning hostcontract ro-planning-intent-v2
Route Optimizer (RO)separate system: Python planning engine

Results become route plans, with attention and quarantine paths.

Verified Architecture Diagram Checked against the RouteDawg repository and database, October 2026.
ManagerCompany role

Reads the company's data

rd_read_staff
DispatcherCompany role

Reads the company's data

rd_read_staff
DriverCompany role

Reads only their own rows

rd_read_driver
AdminPlatform operator

Acts through server-side SQL functions, not through a row-level policy

no RLS policy

Writes: the trusted command role is limited to its own company (rd_command_own_org).

Verified Architecture Diagram Roles and policy patterns from the RouteDawg database, October 2026.