Supply Chain Visibility and Tracking

Multi-carrier shipment tracking

Design a platform that collects tracking events for international shipments from many carriers in many formats, turns them into one reliable timeline per shipment, predicts arrival, and alerts the right people when a shipment runs late.

Overview

A container going from Shanghai to a warehouse in Ohio passes through many hands: the factory, a freight forwarder, a trucker, the terminal, the ocean carrier, customs, a railroad and another trucker. Each of them knows a piece of where the box is, and each reports it differently. A visibility platform gathers those pieces and answers two questions for the customer: where is my shipment now, and when will it really arrive?

The hard part is not storage or traffic. It is data quality. Some carriers push clean API events within seconds. Others send EDI 214 status messages (the X12 standard for carrier shipment status) in batches hours later. Some only email a spreadsheet. Vessel positions come from AIS, the radio beacons ships broadcast. The same event can arrive three times from three sources, a day late, with a local time and a carrier-specific code. The platform must merge all of it without inventing anything.

Questions to ask first

Which modes? — Ocean containers first, with the truck legs at each end; air later
Who are the users? — Shippers, consignees and forwarders, each seeing only their own shipments
How many shipments? — About 2 million active at once, each about a month long
How fresh must the timeline be? — Within a minute of receiving an event; the source itself may be hours late
What counts as late? — The predicted arrival is more than 2 days after the promised date (the customer sets this)
Do we predict arrival ourselves? — Yes, and we show the carrier's estimate next to ours

What you will be able to do

Explain why normalization, matching and deduplication are the core of the problem, not the database.
Design a canonical event model that keeps actual, estimated and planned events apart.
Make ingestion safe to repeat and correct when events arrive late or out of order.
Describe how an ETA model is trained and judged without leaking the future.
Turn timelines into exceptions that reach the right person once, not a flood of alerts.

Key concepts

Connectors per source
Canonical event model
Actual vs estimated events
Idempotent ingest
Event time vs arrival time
Shipment matching
ETA prediction
Exception rules
Party-scoped access

Functional requirements

Register a shipment with its identifiers (container number, bill of lading, booking reference)
Collect events from carrier APIs and webhooks, EDI 214 messages, an AIS position feed and parsed emails
Show one timeline per shipment with each event's source, time and place
Show the current status, the carrier's estimated arrival and our predicted arrival
Open exceptions (late, tracking gap, hold) and notify the people who own them
Each party sees only the shipments it is a party to

Non-functional requirements

A received event reaches the timeline within 1 minute (a target we chose)
Never show a status no source reported; unknown codes wait for review
Ingest is idempotent: replaying a message or a whole day changes nothing
Timeline reads answer in under 300 ms at p99 (a target we chose)
Keep raw messages so any timeline can be rebuilt after a mapping fix

Interview questions

How do you normalize events from hundreds of carriers into one timeline?
Events arrive late, twice and out of order. How do you keep the timeline right?
How do you match an event to the right shipment?
How would you build and judge the ETA model?
How do you avoid flooding people with alerts?
How do you keep one customer from seeing another's shipments?
What would you store where?