Design a Supply Chain Tracking DApp

Problem statement

Design a Supply Chain Tracking DApp that enables every participant in a product's lifecycle—manufacturer, shipper, warehouse operator, distributor, retailer, and end consumer—to record, verify, and query the provenance and movement of physical assets on a permissioned or consortium blockchain. The system must register assets at creation, track ownership transfers through each handoff, integrate IoT sensor data for real-time condition monitoring, enforce multi-party access control, and provide consumers with a final verification mechanism to confirm product authenticity.

This is not a single-company inventory system. A supply chain involves 5-20 independent organizations, each with their own IT systems, trust levels, regulatory obligations, and competitive interests. No single party can be the authoritative source of truth because every participant has an incentive to misrepresent or withhold information. The blockchain serves as a shared, tamper-evident coordination layer that provides cryptographic proof of provenance without requiring any party to trust another.

Why the problem is distinctive

A traditional database supply chain system requires a single trusted operator. When Walmart tracks lettuce from a farm in Salinas to a store in Dallas, every intermediate handler—packing house, cold-chain trucker, distribution center—must report into Walmart's system. If any participant falsifies data or experiences a system outage, the chain of custody breaks. The DApp replaces centralized trust with cryptographic consensus: each participant signs their events with their private key, the network reaches agreement on ordering, and the resulting ledger is immutable once committed.

The attached brief requires asset registration, multi-party access, IoT integration, consumer verification, scalability for thousands of daily updates, security against tampering, reliability when nodes go offline, and GS1 compliance. The section rhythm, visual vocabulary, recap contract, quiz placement, multi-cloud diagrams, and WinSystemDesign Friend rules follow the orchestrator and master prompt. The field shapes and multilingual code contract follow the course profile metadata.

Public operating baseline versus design assumptions

Public evidence establishes the category is operationally real. IBM Food Trust reports tracking over 500 suppliers and 50,000+ products across Walmart's supply network. Maersk and IBM's TradeLens platform processed over 30 million shipping events before its 2022 shutdown, demonstrating both the scale achievable and the governance challenges that can kill consortium projects. De Beers' Everledger platform has registered over 2 million diamonds on blockchain for provenance tracking. VeChain reports integration with BMW, Walmart China, and DNV for supply chain verification.

For capacity planning, this answer explicitly assumes a mature consortium network with 50 registered organizations, 200 active participants, 50,000 assets under tracking, 10,000 on-chain events per day, and a 5× peak multiplier during seasonal shipping surges. Unless a number is tied to a citation, it is a stated design assumption.

The four architectural planes

1. Consensus plane: permissioned blockchain network, ordering service, endorsement policies, and channel governance.
2. Asset plane: smart contracts for registration, ownership transfer, condition attestation, and lifecycle state machines.
3. Integration plane: IoT gateways, ERP connectors, barcode/QR scanners, GS1 EPCIS event ingestion, and off-chain data storage.
4. Consumer plane: verification APIs, mobile scanning, provenance dashboards, and regulatory reporting.

A strong interview answer keeps these planes separate. It allows the consumer plane to degrade without weakening the consensus plane, and it permits the integration plane to buffer events without silently altering the validated asset state.