Problem Statement: Real-Time Shipment Tracking
Problem Statement: Real-Time Shipment Tracking — real-time order tracking for e-commerce
Problem Statement: Real-Time Shipment Tracking
Amazon, FedEx, and UPS built their reputations on predictable delivery visibility. A shopper expects a single timeline — label created → picked up → in transit → out for delivery → delivered — plus a map or ETA that updates without a refresh. The design challenge is to unify three different data sources into one coherent experience: the merchant's order state, the carrier's scan events, and the last-mile GPS/telematics.
The architectural spine, stated up front, is the separation of canonical milestones from kinematics. Milestones are durable, ordered, and legally meaningful (the official "delivered" scan); kinematics are the noisy, high-frequency GPS/telematics stream. Carriers each speak a different dialect, but the platform speaks one canonical enum — every carrier event is normalized to the same milestone vocabulary. And the ETA is a recomputable view, not a second source of truth — it is derived from the milestones and transit history, never stored as an authoritative fact that can drift from the log. The whole system is built on an append-only event log from which milestones are projected, with idempotent carrier ingestion at the front (carriers replay, retry, and deliver out of order).
The product promises that follow: buyers see authoritative milestones within seconds of carrier acceptance; support agents explain delays using the same event log shoppers see; public tracking links work for gift orders without leaking the full address; and notifications fire once per meaningful transition, not on every GPS tick. The scale anchors: 8M shipments/day, ~1.6 concurrent viewers per active shipment at dinner peak (~1.8M concurrent viewers), and webhook bursts of 40K events/s when regional hubs scan pallets. The failure to avoid from the outset is treating GPS as the source of truth (it is noisy and gappy — ground line-haul often has none); the milestones are the truth, GPS is a garnish. The principle: ingest carrier webhooks idempotently, project ordered canonical milestones from an append-only log, coalesce noisy telematics, and treat ETA as a recomputable view — one timeline from many carrier dialects.
Key Highlights
- •Unify three sources into one timeline: merchant order state + carrier scan events + last-mile GPS; carriers speak different dialects, the platform speaks one canonical milestone enum
- •Architectural spine: separate durable ordered canonical milestones (the truth, legally meaningful) from noisy kinematics (GPS); ETA is a recomputable view, not a second source of truth
- •Scale: 8M shipments/day, ~1.8M concurrent viewers at dinner peak, 40K webhook events/s burst when hubs scan pallets; idempotent ingestion + append-only log + project milestones; notify once per transition
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Real-Time Shipment Tracking, I normalize carrier codes before they touch customer-visible state."
- "I'll size webhook ingress separately from buyer poll traffic—bursts are not symmetric."
- "Milestone truth stays in an append-only log; ETA is a derived, replaceable projection."