All WorkMerchant Tooling · Infrastructure
Type
Reference Architecture
Platform
Shopify Plus
Systems
ERP · CRM · PXM
Adapters
NetSuite · HubSpot · Salsify
Services
Adapter ArchitectureMulti-TenancyMessage BusConflict Resolution
Stack
Node.js · TypeScript · Hono · BullMQ · Redis · PostgreSQL · Drizzle ORM · React
The Challenge
Every system of record wants to own the same data — reliably, across many tenants at once.
This is the wall Plus merchants hit at scale: orders need to land in NetSuite as SalesOrders with B2B purchase order numbers and Net 30/60/90 terms, inventory flows back on a 15-minute polling cycle, customer records sync to HubSpot with lifetime value enrichment, and product content published in Salsify has to materialize as Shopify products and metafields.
Each integration has its own auth scheme, data model, failure modes, and conflict surface — and they all have to run reliably across many merchant tenants at once. The hub answers with a small, opinionated core that pushes all system-specific behavior into adapters, config, and per-tenant data.
3
Production adapters · NetSuite / HubSpot / Salsify
11
Postgres tables behind full multi-tenancy
4
Conflict strategies, configurable per mapping
167
Tests across 34 files
The Approach
A small core, a strict adapter contract, and queues that never lose a failure.
01
One adapter interface
Every external system implements connect, disconnect, healthCheck, pull, and push over a shared BaseAdapter that owns retry, error classification, logging, and metrics. Enabling NetSuite for a new merchant is a row in the database, not a deploy.
02
Tenancy at every layer
A tenant context middleware plus a scoped DB helper put an explicit tenant predicate on every query — forgetting a where-clause should not be a quiet correctness bug. RBAC resolves per-tenant roles on every mutating route.
03
Transform & conflict engine
Per-tenant field mappings, type coercion, and checksum-based change detection ahead of every write. When both sides changed, one of four strategies decides — source wins, target wins, most recent, or manual review — with both versions audit-logged.
04
Queues with a live DLQ
Inbound, outbound, and dead-letter queues on BullMQ, with an error classifier splitting transient from permanent failures. The dashboard surfaces the DLQ with retry and resolve actions, and alerts fire when it crosses a threshold.
44-second film · silent · loops
The Outcome
Demo mode included
Integration work stops being a special project and becomes a routine.
Adding a fourth or fifth adapter — Acumatica, Klaviyo, Algolia — means writing a new BaseAdapter subclass and a manifest; the SyncManager, transform engine, queues, DLQ, metrics, and dashboard pick it up without a code change. A DEMO_MODE switch boots the whole system in memory with 24 hours of seeded sync activity, so reviewers explore the architecture without Docker, Redis, or Postgres running.
The dead-letter queue is not a graveyard. Failures become work items rather than pages that silently pile up.
