Walk through a single supply-chain workflow in which all four oracle patterns appear at once. Which pattern does each job?
One order-to-delivery flow uses every pattern: a credit check (pull-based inbound), a QR scan of a received package (push-based inbound), a back-office update (push-based outbound), and a buyer tracing the goods (pull-based outbound).
* One order-to-delivery process uses all four at once — arrows toward the ledger are inbound, away from it are outbound; the label gives each one's initiator (pull/push) and its job. *
The four patterns aren't alternatives you choose between — a realistic process weaves several together, because data crosses the on-/off-chain boundary in both directions and gets initiated from both sides. Picture a bulk buyer ordering goods from a manufacturer, with the workflow anchored on a blockchain:
| Step in the workflow | What the oracle does | Pattern |
|---|---|---|
| Vet the buyer | An order is placed and a smart contract emits an event; the oracle catches it and calls an external credit-assessment API to check the buyer's creditworthiness before the order proceeds | Pull-based inbound — the chain requests outside data |
| Register a package | A warehouse employee scans a package's QR code (order ID, product, quantity); the oracle enriches the scan with location and timestamp and writes it on-chain | Push-based inbound — an off-chain event is pushed in |
| Update the back office | The resulting on-chain "goods received" event is caught and forwarded to the company's ERP system so it can act on it | Push-based outbound — a chain event is pushed out |
| Trace the order | The bulk buyer's web app queries the chain on demand to follow production and shipment | Pull-based outbound — the outside world reads the chain |
The lesson: treat the patterns as a toolkit, not a menu. Recognising which cell each interaction falls into is what lets you reason separately about each one's latency, cost, and trust profile — the whole point of naming them as distinct patterns.
Go deeper:
Foundational Oracle Patterns (Mühlberger et al., arXiv) — the worked supply-chain use cases (creditworthiness verification and QR-code goods tracing) that exercise all four patterns in one process.