B2B Order Entry API (v3 Migration) In Progress
Rebuilt a legacy .NET order pipeline on Bun and Hono and shipped its B2B and storefront order lanes behind a quote-to-submit checkout contract, under 299 passing tests.
Private employer Details are sanitized; architecture and outcomes are described without proprietary identifiers.
At a glance
- passing tests across 28 files
- 299
- warehouses ranked for every order
- 14
- outcome codes shared by both order lanes
- 16
- Role
- Lead Full Stack Developer
- Year
- 2026
- Category
- Backend Software Dev
About This Project
Replaced a legacy .NET and PHP order intake stack with a Bun and Hono B2B API inside the v3 monorepo. Authored the 974-line team reference that specifies the eight-step order pipeline, the hybrid inventory model, the idempotency contract, and a 16-code outcome catalog, then built it end to end: SKU and promo validation, UPS warehouse ranking across 14 sites, case-aware stock allocation, and a fail-closed processOrder orchestrator behind both a public POST /orders route and the storefront cart submit, sharing one idempotency store. The storefront lane grew into a full checkout contract: a priced quote that composes quantity-break pricing, promo tiers, sales tax, freight, and the warehouse allocation plan, a validate gate, and a submit that only places the exact quote the buyer reviewed, proven end to end through placed orders on the dev stack, with a re-visitable receipt and nine read-only order history routes over the ERP. The ERP dispatch leg and the cutover off the legacy intake route are planned entries in the 34-item go-live register; the platform search layer built alongside this work has its own case study.
Engineering Deep Dive
How a strangler cutover from a legacy .NET order pipeline to Bun and Postgres is de-risked by an executable parity harness: same payloads through both implementations, JSON-diffed until they agree.
Read the engineering deep diveTechnologies Used
Engineering Challenges
01
Hybrid Inventory Model
Synced the slow-moving validation rules such as minimum order quantity, case quantity, and dropship flags into Postgres, while reading per-warehouse quantities live from DB2 at allocation time so stock stays authoritative with no cache to invalidate.
02
Third-Party Ranking Resilience
UPS rating drives warehouse ranking, so the service walks five tiers before it fails: cached rankings, stored rankings (rejecting fabricated all-far results), live UPS rating in parallel, Haversine distance from ZIP geocoding, and a state default seeded for all 50 states and DC. Only live builds persist, stale rankings serve while they rebuild in the background, and every fallback emits a structured event.
03
Quote-to-Submit Checkout Contract
The storefront needed one server-side answer to what an order will cost and whether it can be placed, before any write. The quote composes the pricing engine, promo tiers, sales tax, freight, and the allocation plan on a version-stamped cart, a validate gate re-judges every precondition, and the submit reuses the allocation plan the quote already judged instead of allocating twice. The cart completes inside the order transaction only while its quote version is unchanged, so a cart edited mid-submit rolls the order back with a 409 instead of placing a stale order. An end-to-end walk then caught a submit outlasting the client timeout while the order was placed; the client now keeps its idempotency key and quote version when no answer arrives, so the next click replays the placed order instead of failing on a closed cart, and a double-click still writes exactly one order.
Technical Highlights
Tested Service Layer: 299 order tests across 28 files cover the orchestrator, allocation, categorization, warehouse ranking, UPS rating and OAuth, ZIP geocoding, idempotency, promo codes, the submit lane, receipts, and order history.
Fail-Closed Orchestrator: processOrder runs idempotency, customer preferences and ship-to, promo, warehouse ranking, live DB2 SKU validation, line categorization, and allocation, then writes the order and its lines in one transaction. Any unexpected error returns 422 instead of a partial order, and an exhaustive status map answers 201, 200, 409, or 422 per outcome.
Idempotency Contract: Header-based keys with a SHA-256 canonical body hash, distributed in-flight locking through a Redis lock with a Lua release script, and replay of the original response instead of a duplicate order, shared by the B2B and storefront lanes.
Case-Aware Allocation: Walks the ranked warehouse list allocating full cases before remainders, prefers near warehouses that can fulfill outright, merges repeat assignments, and reports results through 10 blocking error codes and 6 non-blocking warnings that integrators and parity tests share as one vocabulary.
Token-Scoped Security: Customer identity resolves from the API credential or buyer session, never from the request body. No history route accepts a customer identifier, and another customer's order answers 404, never 403, so order numbers cannot be probed.
Journal Change Capture Study: To keep ERP-owned stock and status fresh without re-scanning about 1.2 million rows per sync, measured a change-data-capture approach that tails the ERP's existing journals over the same read-only ODBC connection, with zero changes on the ERP side. A dry-run poller ran six days against the production journal: 25,316 cycles, cycle time p50 92 ms and p95 242 ms, freshness lag p95 7.4 s, zero sequence violations, and unaided recovery from receiver rotations and VPN outages. Verdict GO; the daemon is the next build.
Business Logic
B2B Channel Enablement: API integrators gain programmatic order placement instead of a manual email intake workflow.
Self-Service Ordering: Storefront buyers see a priced, validated quote before they submit, then revisit printable receipts and check open orders, invoices, tracking, and quotes online instead of calling customer service.
Platform Modernization: Moves order logic off SQL Server stored procedures into a testable Bun service aligned with the broader v3 stack.
ERP Alignment: Preserves ERP ownership of pricing and final confirmation while the API owns sourcing decisions and structured responses.
Release Risk Reduction: Phased user stories, a parity harness against the legacy suite, a five-gate study program that turns 39 legacy feature areas into build plans, and a 34-entry go-live register with its own decision sheet keep every cutover step, data catch-up, and production provisioning item planned in one place instead of in TODO comments.