Dev log · Systems
Blockchain Order Management: PostgreSQL Meets Hyperledger Fabric
9 min read
Not every order needs to live on a blockchain — but audit trails that no single party can tamper with? That’s a different story. I built a Blockchain Order Management System that combines the speed of PostgreSQL with the immutability of Hyperledger Fabric.
The requirement
- Fast dashboards — filter thousands of orders by date, status, customer
- Tamper-evident history — proof that order records weren’t altered after settlement
- Multi-party trust — supplier, distributor, and auditor reading the same truth
Pure on-chain storage fails the first requirement. Pure PostgreSQL fails the second. The answer is a hybrid ledger.
Architecture overview
Client (JS) → REST API (Node.js)
├── PostgreSQL (operational data, queries)
└── Fabric SDK (hash + anchor to ledger)PostgreSQL layer
Stores everything the UI needs day-to-day: orders, line items, customers, statuses, timestamps. Normal indexes, JOINs, reporting — all the stuff blockchains are bad at.
Hyperledger Fabric layer
When an order reaches a milestone, the API writes a compact event record to the chain: order ID, status transition, hash of the canonical snapshot, timestamp, and actor identity. We don’t store full payloads on-chain — only fingerprints.
Write path
- API validates and persists order to PostgreSQL inside a transaction
- On success, enqueue a Fabric transaction (async to avoid blocking the user)
- Chaincode appends immutable record; callback updates ledger_tx_id on the order row
- If Fabric is temporarily down, retry queue holds events — operational DB stays available
This was key: the app stays usable even when the ledger is slow or unavailable. Blockchain augments trust; it doesn’t block business.
What I learned
- Put blockchain at the edge of your domain — anchoring and verification — not at the center
- Design for ledger downtime from day one
- Hash snapshots, don’t dump JSON on-chain
- Document the verification story for non-blockchain stakeholders