Choosing the Integration Backbone

The backbone is whatever carries messages between the systems in the reference architecture. The general broker comparisons live in the data-engineering cluster (RabbitMqVsKafka, KafkaAlternativesCompared, NatsAndJetStream); this page is the commerce-specific decision: which fabric, at which tier, with which boundaries synchronous.

First: Cron Is a Backbone

At garage tier the correct backbone is often no broker at all: polling loops on a schedule, reading state via API and writing deltas. Polling is self-healing (a missed cycle is caught by the next), trivially debuggable, and idempotent by construction if consumers follow the set-don't-increment rule. Its cost is latency — minutes, not milliseconds — which maps directly onto the oversell window (DataConsistencyAndSyncPatterns). Graduate individual flows to events when that flow's latency costs money, not wholesale.

The Three Broker Families for Commerce Duty

RabbitMQ — the work-queue default (growth tier's sweet spot). Classic AMQP queueing: per-message acknowledgment, retries, dead-letter exchanges, competing consumers — exactly the reliability ladder from IntegrationPatternVocabulary, natively. Order flows are work queues at heart (this order needs picking — exactly one station should take it), which is why RabbitMQ fits commerce integration so naturally. Operationally modest: runs happily on one node at growth scale.
Kafka (or Redpanda) — the durable log (enterprise tier). A replayable, ordered, retained event history. It earns its considerable operational weight when you have many consumers of the same events (OMS events feeding fulfillment, analytics, finance, and search independently), when replay matters (rebuild a projection, backfill the warehouse, audit a dispute), and when CDC pipelines arrive. It is a poor fit for per-message work-queue semantics — which is why mature stacks often run both: Kafka as the event log, RabbitMQ for task dispatch.
NATS/JetStream — the lightweight unifier. One small binary covering pub-sub, queueing, and persistence; the best fit when the whole stack is self-hosted on modest hardware and you want one fabric instead of two. Trade-off: a smaller connector/tooling ecosystem than either incumbent — you'll write more glue.

Postgres-as-queue deserves honorable mention: SELECT … FOR UPDATE SKIP LOCKED on a jobs table is a real queue with ACID semantics, zero new infrastructure, and full SQL observability. For a garage-to-early-growth stack already centered on one Postgres, it beats introducing a broker — its ceiling is throughput and fan-out, and reaching that ceiling is a good problem.

Sync vs Async: Where the Boundary Goes

The commerce rule of thumb: synchronous where a human is waiting and the answer changes what they see; asynchronous everywhere else.

Interaction	Mode	Why
Checkout → payment authorization	Sync	Customer is watching; failure must surface now
Checkout → tax/shipping quote	Sync (cached)	Same, but cacheable and degradable
Order → fulfillment release	Async	Nobody is waiting; reliability beats latency
WMS → storefront stock sync	Async	Continuous loop; latency = oversell window
Shipment → customer notification	Async	Obviously
Anything → ERP financial postings	Async (batched ok)	Finance cares about completeness, not seconds

Two hard-won corollaries. Never put a broker inside a synchronous user path — request-reply over messaging adds failure modes without adding value (IntegrationPatternVocabulary). And every sync call needs a degradation story (timeout, retry budget, fallback), because the checkout path inherits the availability of everything it calls synchronously — which is the strongest argument for keeping that list short.

The API Gateway Layer

Separate concern from the broker: the gateway fronts your synchronous APIs (storefront APIs, partner/3PL APIs, webhooks in) with auth, rate limiting, and routing. Open-source default picks: Kong or Apache APISIX (both OSS cores; watch the open-core edges), or plain Traefik/nginx at garage tier where "gateway" means TLS + routing. A gateway is Tier 2+ equipment; a garage stack exposing one storefront API needs a reverse proxy, not a product.

The ESB Trap, Restated for 2026

The failure mode that killed the ESB — business logic migrating into the middleware until the pipe is an unversioned, untestable application — recurs today inside iPaaS tools and broker plugins. The guard: the backbone carries and routes; it does not decide. Translation, enrichment, and routing rules live in owned, versioned, testable services at the edges (IntegrationMiddlewareAndTooling); the broker config stays boring enough to recreate from a README.

Backbone by Tier

Tier	Backbone
Garage	Cron + APIs; Postgres jobs table where queueing is needed
Growth	RabbitMQ (or NATS for the one-fabric self-host aesthetic) + outbox
Enterprise	Kafka/Redpanda event log + CDC; RabbitMQ retained for work queues; gateway at the edge