Freight & Package Delivery Logistics Platform — end-to-end flows

Reference example for the flow-diagram skill · solid blue = OUT direction · dashed green = RETURN direction · red = ID/PIN checkpoint · small arc = two lines crossing, not joining

Click a flow to see it run end to end · Esc to clear · scroll to zoom · drag to pan

100%

Booking → delivery (1→14)

1→2 Customer books a shipment on the Booking Web/App → Booking Service
3/4 Booking Service asks the Route Assignment Engine to match a carrier/driver
5→7 Booking Service → n8n → Pickup Verification → DB (ID/PIN checkpoint)
8→10 Verified pickup + tracking update flows back: DB → Pickup Verification → n8n → Booking Service
11/12 Route Assignment Engine recalculates ETA mid-transit (loop 5→10 repeats on a re-route)
13→14 Delivery confirmation + tracking status shown on the app, then emailed to the Customer

Partner integration API (C1→C7)

C1 A carrier partner's rate-quote request → the Partner API Gateway; C2 the quote is returned through the same gateway
C3 A customs & duties data feed enters through the same gateway — normalized on the way in
C4 Gateway reads/writes the Partner Rate & Customs Store — never accessed directly
C5 If a customs lookup changes a shipment's declared duty, the gateway writes back to the core DB, alongside the analytics sync
C6/C7 An n8n-based job matches the stored rate table and writes back an updated quote — both through the gateway's own endpoint

Analytics pipeline (D1→D6)

D5/D6 Self-serve query: n8n → Ops-Safe Analytics Layer (read-only, mart only) → warehouse → on-time metrics back → n8n → Route Assignment Engine (used to weigh carrier choice)
D1 Shipment & Tracking DB → Airflow, incremental ingest
D2 Partner rate/customs store + external feeds → staging, tagged with source_system
D3→D4 Airflow ETL → Data Warehouse → Ops Dashboard

Driver settlement job (S1→S4)

S1 Booking Service schedules a nightly cron → triggers the n8n settlement workflow
S2 n8n reads completed shipment records (service account) directly from the Shipment & Tracking DB to compute driver payouts
S3 Batch computed → the payout-ready event fires so finance can disburse
S4 Job failure → alert to internal ops (Discord) for the on-call engineer

Document generation (M1→M7) — 2 paths

Path 1 (via n8n): a new booking or customs-flag event → n8n → M1 calls the Document Generation Service → M2 draft returns to n8n → M3 saved to the Draft Document Store
Path 2 (data-driven redraft): M4 the Customs Data Extraction Service calls the Document Generation Service directly, M5 draft comes straight back
M6 queued in the Document Review Queue → M7 ops/compliance approves before it's attached to the shipment

Locked-in principles

Only Booking Service calls the Route Assignment Engine; every downstream step routes through n8n in both directions
The Partner Rate/Customs Store is only read/written through the Partner API Gateway; the warehouse is only read through the Ops-Safe Analytics Layer (staging and the production DB are never queried directly)
ID/PIN checkpoint: Pickup Verification sees exactly the shipment it's releasing, nothing more
The Vault/audit log records every flow; alerts split into two channels (business vs. technical)
Human review is mandatory before any generated shipping/customs document is attached to a shipment