Real-Time Shipment Tracking & Logistics Optimization Platform

Client Overview

The client is a Pune-based, mid-size logistics company specializing in last-mile delivery for e-commerce platforms, pharmaceutical distributors, and FMCG brands across India. Founded in 2014, the company grew from a regional courier service in Maharashtra into a national operation covering more than 50 cities — with a network of over 2,000 active delivery partners and processing upwards of 80,000 shipments per day at peak.

The company operates a hub-and-spoke model: goods are consolidated at regional sorting hubs, then dispatched to micro-fulfilment centres and finally assigned to individual delivery partners (DPs) for last-mile execution. The client serves a mix of B2B clients — including one of India's top-5 e-commerce platforms — and a growing B2C same-day segment in Tier 1 cities.

Their competitive positioning relies entirely on delivery speed and reliability. On-Time Delivery (OTD) percentage and real-time customer visibility are the two KPIs that determine whether large e-commerce clients renew annual contracts. By late 2022, both were in serious jeopardy.

The Challenge

A Legacy Monolith at Its Breaking Point

When Xortrix AI first engaged with the client, their core operations ran on a six-year-old Java monolith deployed on a fleet of manually provisioned EC2 instances behind a classic Elastic Load Balancer. The application handled everything: order ingestion, DP assignment, route planning, customer notifications, invoice generation, and reporting — all in a single deployable WAR file. The database layer was a heavily over-provisioned RDS MySQL instance (db.r5.4xlarge) that had accumulated years of schema debt, with no read replicas and no connection pooling outside the application itself.

The monolith had grown to over 340,000 lines of code with minimal test coverage (estimated at 11% by automated analysis). Deployment cycles required full application restarts, meaning even a minor bug fix in customer notification logic triggered a 12-to-18-minute downtime window. The team was deploying roughly once every three weeks — not because features were ready in three-week cycles, but because each deployment was a ritual risk event that required a Saturday-night maintenance window and two senior engineers standing by.

No Real-Time Visibility

Delivery partners carried Android handsets running a proprietary DP app that sent GPS location updates to the backend every 90 seconds — when it worked. In practice, the GPS polling endpoint was part of the monolith's REST API, and under moderate load (typically mid-afternoon on weekdays) the endpoint response times ballooned beyond 8 seconds. The DP app had a 10-second timeout, leading to silent location update failures. Ops teams discovered this only through downstream complaints: customers calling the support line because the tracking page showed their shipment as "Out for Delivery" with a last-known location from four hours ago.

The tracking dashboard used by operations managers was a polling web page that refreshed every 60 seconds and rendered a static map image generated server-side via Google Static Maps API. There were no live updates, no geofencing alerts, and no automated escalation when a delivery partner went off-route. Supervisors caught exceptions reactively — when a shipment missed its SLA window and a client emailed to ask what happened.

Festive Season as the Forcing Function

The immediate trigger for the project was the Diwali 2022 season. The client's largest e-commerce partner ran a 10-day sale event that pushed daily shipment volumes to 3.1x the typical daily average. The monolith began exhibiting cascading failures on day two of the sale: the GPS update queue backed up, the database hit its connection limit (max_connections was set to 500; the pool exhausted at 487), and the customer-facing tracking page returned 502 errors for roughly 40% of requests during a four-hour window on the third day. The company received a formal penalty notice from their e-commerce client citing SLA breach and was placed on a performance improvement plan with a six-month deadline.

Summary of Pain Points

Solution Architecture

After a four-week discovery phase — which included codebase archaeology, load testing the existing system, and running event storming sessions with the client's ops and product teams — we arrived at a target architecture built entirely on AWS managed and serverless services. The guiding principle was operational simplicity: no EC2 instances for application logic, no manually provisioned databases at capacity, and no deployment ceremonies.

The architecture is fundamentally event-driven, built around an immutable event log with Command Query Responsibility Segregation (CQRS) and event sourcing patterns to separate write throughput from read performance — a critical consideration when the same underlying domain data (a shipment's state) needs to be consumed in wildly different shapes: raw GPS stream for the ops dashboard, aggregated delivery metrics for the client portal, and structured events for downstream billing and compliance systems.

Core AWS Services

Architectural Patterns Applied

The platform is built around three interlocking architectural patterns that address different failure modes of the original system.

Implementation Details

Real-Time GPS Ingestion Pipeline

The GPS ingestion pipeline is the highest-throughput component of the platform, and the one that most directly failed in the previous system. We rebuilt it ground-up using AWS IoT Core as the connectivity layer and Kinesis Data Streams as the ingest backbone.

Each DP handset runs the updated delivery partner app (React Native, rewritten as part of this engagement) which establishes a persistent MQTT connection to AWS IoT Core over TLS 1.3. Each device is provisioned as an IoT Thing with a unique X.509 client certificate generated during the onboarding flow, eliminating the shared API key that the original system used for all 2,000+ devices. MQTT Quality of Service is set to QoS 1 (at-least-once delivery), ensuring location updates are not silently dropped even if the handset briefly loses connectivity — the client will redeliver on reconnect.

GPS payloads are published to the topic patternlogistics/dp/{dpId}/locationwith a compact JSON body containing latitude, longitude, accuracy radius, speed, bearing, battery level, and a client-side timestamp. An IoT Rule evaluates every message matching this topic pattern and writes it to a dedicated Kinesis Data Stream (10 shards, supporting up to 100,000 records/second aggregate). The IoT Rule also performs a lightweight SQL-like filter to discard records where GPS accuracy exceeds 50 meters — a common condition in dense urban areas where reflected signals produce spurious location readings that would otherwise pollute the delivery trail.

A Kinesis consumer Lambda function — configured with a batch size of 200 records, a parallelization factor of 3 per shard, and a bisect-on-error retry policy — processes the stream. For each batch, it groups records by DP ID, deduplicates by timestamp within a sliding 5-second window (using a Redis sorted set as the dedup store), and writes the cleaned location events to DynamoDB in batched writes. DynamoDB TTL is set to 90 days for raw GPS events; aggregated daily route polylines are retained indefinitely.

The update frequency moved from 90 seconds to 10 seconds per DP without any polling — a 9x improvement in location freshness — at a fraction of the previous infrastructure cost, because MQTT connections over IoT Core are priced per message, not per persistent compute resource.

Geofencing for Delivery Zones

The client divides each city into a set of named delivery zones: polygons defined by a GeoJSON FeatureCollection stored in S3 and cached in Lambda memory on cold start (typical file size: 380 KB for a metro with 120 delivery zones). Zone definitions are versioned in S3 and Lambda functions are notified of updates via an S3 event notification → EventBridge rule, triggering a cache invalidation across all warm Lambda instances.

After each GPS event batch is committed to DynamoDB, a geofencing Lambda evaluates whether each DP has crossed a zone boundary since their last recorded position. The point-in-polygon test uses the ray-casting algorithm implemented in TypeScript with no external dependencies — benchmarked at under 0.4ms per polygon evaluation on a Lambda with 512 MB memory. For DPs assigned to more than one zone (common during cross-zone deliveries near boundaries), all candidate polygons are tested in parallel usingPromise.all.

When a boundary crossing is detected, aGeofenceBreachedevent is published to EventBridge with the DP ID, zone names (from and to), timestamp, and coordinates. Downstream consumers include:

Amazon Location Service was evaluated as an alternative for geofencing but rejected: its update latency (designed for lower frequency batch evaluation) was incompatible with our 10-second GPS cadence, and its pricing at the client's volume was approximately 4x more expensive than the custom Lambda implementation.

Automated Dispatch Optimization

The original dispatch process was manual: a zone supervisor would receive a WhatsApp message from the hub scanner listing the day's shipments for their zone and then assign them to available DPs based on personal judgment — typically proximity to the first stop and subjective assessment of workload. This produced highly variable route efficiency: some DPs would cover 45 km in a day while an adjacent DP covered 18 km with an equal number of stops.

We built an automated dispatch optimization engine implemented as a Lambda function invoked by a Step Functions state machine that runs at configurable dispatch windows (6:00 AM, 9:00 AM, and 12:00 PM IST for same-day orders). The algorithm is a Clarke-Wright savings heuristic implementation — a classical VRP (Vehicle Routing Problem) solver that runs in polynomial time and is well-suited to the size of the client's typical dispatch batch (50–400 stops per zone per window).

Inputs to the optimizer: the set of unassigned shipments with delivery addresses geocoded to lat/lon (geocoding is done at order ingestion time via the Google Maps Geocoding API with results cached in DynamoDB), the set of currently available DPs with their last known position and their scheduled shift end time, vehicle capacity constraints (two-wheeler vs. four-wheeler), and time windows for attempted deliveries (customer-specified preferred slots stored as ISO 8601 intervals). The optimizer produces an assignment of shipments to DPs with a suggested stop sequence for each DP, which is pushed to the DP app via an MQTTlogistics/dp/{dpId}/manifesttopic.

Supervisors retain override capability through the ops dashboard: any auto-assigned manifest can be edited or reassigned with a justification note, which is recorded as aManifestOverriddenevent. Override data feeds a feedback loop: a weekly analytics job aggregates override patterns to identify route constraints not captured in the optimization model (e.g., a gated community that requires a specific entry time window).

WebSocket-Based Live Tracking Dashboard

The operations dashboard is a Next.js application (deployed on Vercel) backed by API Gateway WebSocket API. When a supervisor opens the dashboard, their browser establishes a persistent WebSocket connection to the$connectroute, which triggers a Lambda that records theconnectionIdin DynamoDB alongside the supervisor's assigned zone IDs and their IAM session context.

Location updates and geofence events flow through a Redis Pub/Sub channel keyed by zone ID. A broadcaster Lambda is subscribed to all zone channels and, when an update arrives, queries DynamoDB for all active WebSocket connection IDs associated with that zone, then fans out the update to each connection via the API Gateway Management API. This architecture supports hundreds of simultaneous dashboard sessions without any of them polling the backend — all updates are server-pushed.

The map rendering layer uses Mapbox GL JS with a custom tile layer overlaying the client's delivery zone polygons. DP positions are rendered as moving markers that smoothly interpolate between GPS updates using CSS transitions on the marker translate transform — this avoids visual jumping on the 10-second update cadence. Each marker is colour-coded by DP status: green (active, on-route), amber (idle >8 minutes), red (off-route or SLA at risk), and grey (offline).

The dashboard also surfaces three operational metrics in real time: current completion rate for the day's manifests, estimated SLA breach count (shipments predicted to miss their delivery window based on current pace), and zone-level fleet utilization. These are computed by a Lambda that runs every 5 minutes and caches results in Redis with a 4-minute TTL — serving the initial dashboard load instantly while keeping the metric freshness acceptable for operational decision-making.

Database Design & Caching Strategy

The primary data store is a single DynamoDB table following Rick Houlihan's single-table design principles. All entity types — Shipment, DeliveryEvent, DeliveryPartner, Zone, CustomerNotification, ManifestAssignment — live in one table, differentiated by their key schema:

Global Secondary Indexes (GSIs) cover the main access patterns that cannot be served by the base table keys: all shipments for a given client (GSI1 with CLIENT# partition key), all deliveries by a given DP on a given date (GSI2 with DP# + date sort key), and all active DPs in a zone (GSI3 with ZONE# partition key). DynamoDB on-demand capacity mode means we never pre-provision read/write capacity units — the table scales instantly in response to load without any intervention.

ElastiCache for Redis (cluster mode, 3 shards × 2 nodes each, r6g.large) serves multiple caching roles:

Results

The new platform went live in January 2024 after a 14-month engagement that included discovery, architecture design, phased implementation, load testing, and a parallel-run migration period. The first major stress test was the Republic Day sale period (January 26, 2024), followed by Holi weekend. Both events were handled without incident. The platform then served its first Diwali season in October 2024 — the same event that had caused the 2022 crisis — at 3.4x normal volume with no SLA penalties.

Full Technology Stack

Lessons Learned