Architecture¶

This page sketches the high-level shape of the fictional Northwind Driver App so the knowledge base has a technical section to edit.

Principles¶

Principle	What it means here
Offline-first	The app is fully usable with no connectivity. Work is captured locally and synced later. The network is an optimisation, never a requirement.
One codebase	A single cross-platform codebase ships to both iOS and Android.
Integration-isolated	Every external system sits behind its own adapter, so one outage does not take the app down.
Configuration over code	Route rules and delivery options are data, changeable without a new app release.
Secure by default	Multi-factor sign-in, encryption in transit and at rest, and least-privilege access.

System context¶

The app sits between the driver and two back-end services: the dispatch system, which owns runs and stops, and the maps service, which provides routing. A thin back-end mediates both so the app talks to one stable interface.

Driver
  -> Northwind Driver App (iOS / Android)
       -> App Back-End
            -> Dispatch System   (runs, stops, proof of delivery)
            -> Maps Service      (routing, ETAs)

Sync model¶

Completed work is written to a local queue and flushed in order when the device is online. Each item is retried until the back-end acknowledges it.

{
  "stopId": "stop-1042",
  "status": "delivered",
  "capturedAt": "2026-06-30T04:15:00Z",
  "proof": { "type": "signature", "ref": "blob-77c1" }
}

Conflicts

If the same stop is updated on two devices, the back-end keeps the most recent change and logs the other for review. The app never silently discards a driver's capture.