§03 / THE WORK

1. 01

   Depot Workflow Mapping and Dispatch Pattern Analysis

   Spent four weeks embedded across six depots observing actual dispatch workflows before committing to any data model. Key findings: load assignment in practice was a continuous negotiation between depot coordinators and drivers rather than a one-shot scheduling event; 'confirmed' assignments in the spreadsheet were routinely renegotiated within hours; and the most operationally significant state — a load in transit with no confirmed ETA — had no representation in any existing system. The dispatch data model was built around these observed patterns, treating assignment as a mutable lifecycle rather than a static record.

2. 02

   Centralized Load Lifecycle and Dispatch Orchestration

   Designed a dispatch service that maintains authoritative load state across all depots, with optimistic locking on load-driver assignment pairs to prevent concurrent assignment conflicts that the existing per-depot spreadsheet model could not detect. Load creation, assignment, in-transit transitions, delivery confirmation, and failure recording are modelled as state machine transitions with mandatory actor attribution. No load state can regress — a delivered load cannot be reassigned, and a cancelled load cannot be confirmed — without an explicit exception workflow that writes an audit record.

3. 03

   GPS Telemetry Ingestion and Live Fleet Position

   The existing telematics vendor exposed a webhook stream that had never been integrated into any operational system. A telemetry ingestion service was designed to consume this stream, normalize position and ignition events into the platform's canonical event schema, and publish them to the central event broker. A route adherence service consumes position events and compares vehicle trajectory against the assigned route, emitting deviation alerts when a vehicle departs from its expected corridor beyond a configurable threshold. ETAs are recalculated continuously from live position data and propagated to the load record and to recipient notification workflows.

4. 04

   Driver Hours Compliance Engine

   Driver hours are tracked as an event stream derived from dispatch events and telematics data rather than from self-reported timesheets. Shift start is recorded when a driver is assigned their first load of a day; driving time accumulates from telematics movement events; mandatory rest periods are enforced by the assignment workflow — the dispatch service rejects load assignments to drivers whose projected hours would breach the regulatory limit, routing the assignment to a compliant available driver. The hours ledger is queryable for any driver over any period, producing a compliance record reconstructible from event data rather than paper archives.

5. 05

   Failed Delivery and Rerouting Workflow

   Failed deliveries in the existing system were discovered at day-end when drivers submitted their end-of-day report. The proposed platform detects delivery failures in near-real time: if a driver marks a delivery as failed, a rerouting workflow is immediately triggered that evaluates available drivers within range, checks their remaining compliant hours, and surfaces rerouting options to the depot coordinator within minutes of failure recording. Failed delivery events are linked to the originating load record, customer record, and driver record, enabling failure pattern analysis by route, customer, driver, and depot.

6. 06

   Centralized Reporting and Operational Analytics

   The reporting layer is fed by projection workers consuming the full event stream into a ClickHouse analytical store, maintaining denormalized models for depot throughput, driver utilization, on-time delivery rate, load completion rate, failed delivery frequency, and vehicle idle time. These models are updated continuously rather than rebuilt nightly, giving central operations a reporting view that reflects the current operational state rather than yesterday's. Background reconciliation workers compare planned load schedules against completion records, flagging loads that are overdue for status updates and surfacing them in the operations dashboard before they become day-end surprises.

§06 / ARCHITECTURAL DECISIONS

1. 01

   Why Kafka for the Event Bus

   The dispatch domain produces a continuous high-frequency event stream from three independent sources — user-initiated load state transitions, GPS telemetry position events, and driver mobile app interactions — that must be processed by independent consumers at different throughput and latency requirements. Kafka's partitioned log allows telemetry ingestion, dispatch state processing, compliance monitoring, and analytics projection to consume from the same event stream independently without coupling their processing rates. The durable log also enables the platform to replay the full telemetry and dispatch history for any time window — necessary for incident investigation, compliance audit, and bootstrapping new analytical workloads.

2. 02

   Why Event Sourcing for Load Lifecycle

   Load state in logistics is inherently contentious — multiple actors (depot coordinators, drivers, receiving parties, central operations) may attempt to update the same load record concurrently under time pressure. A mutable record with last-write-wins semantics would silently discard updates under contention. An event-sourced load ledger preserves every state transition attempt, applies them in causal order, and makes conflicts visible rather than hiding them. It also provides the audit depth that regulatory and customer dispute contexts require — the ability to reconstruct exactly who changed a load's status, when, from what device, and what the state was at every prior point.

3. 03

   Why Depot-Local Service Nodes

   Depot operations are time-critical and cannot tolerate WAN latency on the dispatch path. A coordinator assigning a driver to a load, or a driver confirming a pickup, cannot wait for a round-trip to a central data centre under operational time pressure. Each depot runs a local service node that handles read and write operations against a local store, with asynchronous synchronization to the central broker. This architecture means that depot operations continue at full performance regardless of WAN connectivity quality, and that central operations always has a converging — if slightly lagged — view of depot state.

4. 04

   Why Continuous Reconciliation Rather Than Daily Batch

   Daily batch reconciliation in logistics operations is operationally useless — a load that has been in an incorrect state for 24 hours has already caused a cascade of downstream scheduling decisions based on wrong data. Continuous reconciliation workers that run against the event stream detect state inconsistencies within minutes of their occurrence, when the depot coordinator who assigned the conflicting load is still at their desk and the driver is still at the collection point. This changes exception resolution from next-day archaeology to same-session correction.

5. 05

   Why Configurable State Machines for Driver Hours

   Transport hours regulations vary by jurisdiction, vehicle class, and load type — a long-haul HGV driver operates under different limits than a last-mile van driver in the same fleet. Hardcoding hours rules would require engineering changes every time a new vehicle class was added or a regulatory limit changed. Configurable state machine rules allow the compliance team to define hours limits, mandatory rest durations, and exemption categories as versioned configuration without a deployment cycle. Historical compliance records can always be validated against the rule version active at the time of the relevant shift.

§08 / IMPACT

1. 01

   Concurrent Load Assignment Conflicts Eliminated

   Before the platform, cross-depot load assignment conflicts were discovered operationally — two drivers arriving at the same collection point, or a driver arriving for a load that had been cancelled at another depot. Optimistic locking on load-driver assignment pairs at the service layer makes concurrent conflicting assignments architecturally impossible. The conflict class is removed rather than monitored.

2. 02

   Fleet Position Visible in Near Real-Time

   Central operations previously had no programmatic access to vehicle position. The telemetry ingestion pipeline targets a position update lag of under 30 seconds from GPS event to live fleet map. This enables in-progress delivery monitoring, deviation detection, and ETA recalculation that was previously impossible — changing the operations center's role from reactive incident responder to proactive dispatch coordinator.

3. 03

   Failed Delivery Detection Compressed from Hours to Minutes

   Failed deliveries were previously discovered at day-end when drivers submitted their reports. The event-driven rerouting workflow targets detection and rerouting option surfacing within five minutes of a driver recording a delivery failure — while vehicles are still in the field, compliant hours remain available, and the operational window for same-day resolution is still open.

4. 04

   Driver Hours Compliance Converted from Paper to Event Log

   Weekly paper timesheet submission provided no pre-assignment compliance visibility and no reliable reconstruction capability after incidents. The continuous hours event log, derived from dispatch events and telematics data, provides real-time hours remaining per driver before every assignment decision and produces a tamper-evident compliance record reconstructible from event history for any audit window.

5. 05

   TMS Licensing Eliminated at Scale

   The per-vehicle licensing structure of the incumbent TMS made the cost trajectory to 50 depots and the required fleet expansion economically indefensible. The purpose-built platform eliminates per-vehicle licensing entirely. Infrastructure cost scales with event throughput and storage — a sub-linear relationship to fleet size — creating a compounding cost advantage with every additional vehicle and depot enrolled.

§10/ SECURITY & GOVERNANCE