Logistics Software Architecture: Real-Time Tracking, Route Optimisation and the Integration Layer That Makes or Breaks the System

Logistics platforms look like CRUD applications from the outside: orders, shipments, invoices, tracking pages. Under the surface they are real-time, event-driven, integration-heavy systems where partial failure is the normal operating state. Trucks lose GPS signal. Warehouse scanners go offline. Carrier APIs return 500 errors. The architecture must handle all of this without losing data or showing stale information. We have built these systems for freight operators, last-mile delivery companies and supply-chain visibility platforms — and the patterns below are what we now start every logistics project with.

Event-driven core

The central architectural decision in logistics software is event-driven messaging. Every state change — package scanned, vehicle position updated, delivery confirmed, exception flagged — is published as an event. Consumers subscribe to the events they care about: the dashboard reads from a position stream, the alerting system watches for exceptions, the billing system tallies completed deliveries, and the analytics pipeline aggregates everything. This decouples producers from consumers and lets you add new capabilities without modifying existing systems.

Real-time tracking architecture

Vehicle tracking is a write-heavy, read-heavy system with a unique data shape: high-frequency GPS coordinates (one per second to one per thirty seconds per vehicle) that need to be stored, aggregated, displayed on maps, and used for ETA computation. Our architecture: GPS devices or mobile apps publish positions via MQTT or HTTPS to an ingestion endpoint. The endpoint writes to a time-series table (PostgreSQL with partitioning by day) and publishes to a Redis Pub/Sub channel. The map dashboard subscribes to the Redis channel via WebSocket for live updates. Historical queries hit the time-series table with PostGIS spatial indexing.

ETA calculation

ETA is the feature users judge your platform by. A naive distance/speed calculation is wrong by 20-40% in real-world conditions. Our ETA engine factors in: current vehicle position and speed, remaining stops, historical travel times for each road segment by time of day, live traffic data (Google Maps or HERE API), and service time at each stop (loading, unloading, signature). The engine recalculates on every position update and publishes revised ETAs as events. The customer-facing tracking page consumes these events in real time.

The integration layer

Every logistics platform connects to external systems: ERPs (SAP, Oracle, NetSuite), warehouse management systems (Manhattan, Blue Yonder, custom), transport management systems, carrier APIs (FedEx, DHL, UPS, local carriers), and accounting software. These integrations account for 40-60% of the engineering effort on every project. We build a dedicated integration layer with adapters per external system, a canonical data model that all adapters translate to, retry logic with exponential backoff, dead-letter queues for failed messages, and comprehensive logging for debugging the inevitable 'it worked yesterday' support tickets.

Technology stack

Designing for partial failure

Logistics systems operate in environments where failure is normal. GPS signals drop in tunnels and parking garages. Warehouse WiFi has dead zones. Carrier APIs rate-limit or go down for maintenance. The architecture must handle all of this: buffer events locally when the network is unavailable, show 'last known position' with a timestamp when GPS is stale, retry failed integration calls with backoff, and clearly indicate to users when data is delayed. A logistics platform that shows stale data without saying so is worse than one that shows no data at all.