Systems Architecture · Logistics

Event-driven backend redesign for a real-time logistics tracking platform.

A logistics platform handling real-time shipment tracking was hitting hard performance limits under load. A synchronous, monolithic backend was creating cascading failures during peak traffic. We redesigned the core processing architecture from scratch.

4×Faster event processing

99.95%System availability

12msP95 event latency

0Data loss incidents post-launch

The problem

The platform processed shipment tracking events from carrier APIs, transformed them, and pushed updates to end-customers via webhooks and a real-time dashboard. During peak hours — particularly around major shopping events — the synchronous processing chain would back up. Events queued, timeouts cascaded, and customers saw stale tracking data. The engineering team had patched around the problem repeatedly, but the root cause was architectural.

Diagnosis

We spent the first week reading code and watching the system under load. The core problem was clear: every incoming tracking event triggered a synchronous chain — database write, enrichment API call, customer notification, dashboard update — all in a single request. If any step was slow, the whole chain backed up. There was no isolation between workloads and no way to scale individual steps independently.

The redesign

We proposed a full event-driven rewrite of the processing core, keeping the existing API surface and database schema intact to minimise disruption to the rest of the system.

Ingestion layer: All incoming tracking events are written immediately to Kafka. The API response returns in under 5ms regardless of downstream load.
Processing consumers: Three independent consumer groups process events in parallel — enrichment, notification dispatch, and analytics aggregation. Each scales independently.
Redis caching: Latest tracking state per shipment cached in Redis, making dashboard reads instant without hitting the primary database.
Dead letter queues: Failed events are parked for inspection and retry rather than silently dropped — eliminating the data loss incidents that had occurred under the old system.

"The first peak period after launch, the engineering team had nothing to do. That had never happened before. No pages, no manual retries, no angry customer emails." — VP Engineering

Results

Event processing throughput increased fourfold, with P95 latency dropping from ~180ms to 12ms. System availability improved from approximately 97% (with frequent degraded periods) to 99.95% in the three months following launch. No data loss incidents have occurred since deployment.