Use Case · Logistics

Shipment tracking on the Software Lifecycle Cloud

Shipment tracking on KERNSTACK gives every shipment one timeline: carrier webhooks and polling workers write scan events — label created, departed, out for delivery, delivered, exception — into a table keyed by shipment and time, a worker reconciles scans against the order and flags exceptions, and the tracking view customers read is a query over the very rows operations works from.

Functions (WASM)NoSQL TablesContainer WorkersProduct Analytics
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Dispatchers reconcile carrier scans with orders across three portals and a spreadsheet because every carrier speaks a different dialect and none of them is the system of record. The customer’s “where is it” question lands on support, support asks dispatch, dispatch opens two carrier sites — and the answer still starts with “their site says”.

Architecture on the Software Lifecycle Cloud

Carrier events enter as webhooks stored raw (the ingestion pattern) or by a polling worker where no webhook exists; a normaliser maps each carrier’s statuses into the project’s canonical states and appends to the shipment’s timeline. Exception rules — no scan for 48 hours, returned to sender, customs hold — are evaluated by the reconciler and written as flagged rows with an owner, converting silent drift into a work queue.

One timeline, carrier dialects at the border

Normalising at ingest means every downstream consumer — customer page, support tool, dispatcher board — reads the same states and argues about the same facts. When a carrier renames a status, the fix lands in its normaliser, in review, and history can be re-derived from the stored raw events rather than being permanently mis-bucketed.

  • Raw carrier events are kept, so a mapping fix can replay history correctly
  • Exceptions surface as flagged rows with owners instead of ageing silently in a carrier portal
  • The customer tracking page and the dispatcher board are two reads of one table

What remains the carrier’s

The physical truth still originates with carriers; if they do not scan, no platform can invent the parcel’s location. What this removes is your side of the fog: ingestion gaps become visible (expected scan missing is itself a flag), and no shipment’s state depends on a human remembering to check a website.

FAQ

Frequently asked questions

Any that offer webhooks or a tracking API: webhooks store raw through the ingestion route, API carriers get a polling worker. The normaliser per carrier is ordinary code in the project, so carrier quirks are handled where you can review them.

By the reconciler’s rules over the timeline: stalled scans, contradictory states, returns, holds. A flag is a row with a reason and an owner, cleared by a recorded action — the exception queue is data, not a dispatcher’s memory.

Yes — an unguessable tracking key on the shipment row gates a read-only route. The customer sees the canonical timeline; internal notes stay on fields the public handler never returns.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · ComputeFunctionsGo WebAssembly HTTP handlersService · DataTablesServerless key-value and document tablesService · ComputeWorkersContainer workers for long jobsService · InsightAnalyticsProduct analytics on the same fabricIndustry SolutionLogistics Cloud SolutionsLogistics products on KERNSTACK give every shipment one timeline and every exception an owner: carrier scans and status callbacks are stored raw, normalised into canonical states per shipment, reconciled against orders by workers, and surfaced — to dispatchers as an exception queue, to customers as a tracking page reading the very same rows. The fog between “the carrier says” and “our system says” is where this architecture earns its keep.Logistics BlueprintShipment tracking for LogisticsShipment tracking for logistics teams: scans from every carrier normalised per shipment, exceptions flagged, one timeline for everyone.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →