Real-Time Inventory and Order Orchestration in Composable Commerce

Real-Time Inventory and Order Orchestration in Composable Commerce

The most common failure mode of B2B composable commerce is not a slow checkout, a poor product page, or a confusing search experience. It is showing the buyer a product as in stock that is not, accepting the order, and then failing to deliver.

Inventory accuracy in composable commerce is harder than in monolithic platforms, and the difference is architectural: composable commerce decouples the storefront from the inventory system, which means inventory accuracy depends on event-driven integration, not on a shared database.

This article addresses composable commerce inventory orchestration: the architectural patterns, the integration choices, and the engineering disciplines that produce real-time inventory accuracy across the multi-channel commerce stack. It is written for solution architects and senior engineers designing the integration backbone of an Elastic Path-based composable commerce build, but the principles apply across composable platforms.

The article is technical and opinionated. McKenna Consultants delivers composable commerce engagements where the inventory orchestration is one of the most consistent areas where engineering decisions in the first three months determine whether the system holds up at scale or quietly degrades for years.

The Inventory Problem in Composable Commerce

In a monolithic commerce platform, inventory is a single table that the storefront reads, the order capture writes, and the warehouse system updates. Inventory accuracy is fundamentally a database concurrency problem — solvable with row locks, transactions, and predictable behaviour.

In composable commerce, inventory is distributed across systems by design:

• The commerce platform (Elastic Path) holds the catalogue, the price, and the customer relationship.
• The ERP holds financial inventory — accounting state, valuation, supplier relationships.
• The WMS (warehouse management system) holds physical inventory — bins, locations, pick lists, hold reasons.
• The OMS (order management system) holds order state — fulfilment plan, allocations, splits, shipments.
• The storefront displays availability to buyers, often with caching for performance.

These systems do not share a database. They share events. When stock arrives in the warehouse, the WMS publishes an event. When an order is placed, the storefront publishes an event. The other systems respond to events, update their internal state, and may publish further events. Inventory accuracy is the property that emerges from this event flow being correct.

The failure modes of getting it wrong:

Oversells. The storefront shows a product as available, the buyer orders, but the warehouse has none. The order cannot be fulfilled. The buyer is angry, the customer service team has a problem, and the underlying root cause — an event that did not propagate, or propagated late — is often diagnosed slowly because the symptom appears at the buyer end of the system, far from the inventory source.

Undersells. The storefront shows a product as out of stock when it is, in fact, available. The buyer leaves, the order is lost, the warehouse has stock that goes unsold. Less visible than oversells but commercially equivalent.

Drift. The systems’ inventory views slowly diverge over weeks. No single event is wrong; small accumulating errors produce a state where the storefront’s view, the ERP’s view, and the WMS’s view of the same stock differ. Drift is harder to detect than acute failures because there is no single bad transaction to investigate.

Race conditions. Two buyers attempt to purchase the last unit at the same time. Without correct allocation logic, both succeed at the storefront layer, and the conflict is detected only at fulfilment. The pattern is common in promotional events with concentrated demand.

The right architectural response is not to try to recreate the monolithic platform’s database centralisation. It is to design the event-driven integration so that these failure modes are contained, detected fast, and either prevented or mitigated.

Reservation versus Allocation: The Foundational Decision

The first architectural decision is whether your composable commerce system uses reservation or allocation as the core inventory model.

Reservation model. When a buyer adds an item to cart or initiates checkout, the system reserves the stock — marks it unavailable to other buyers — for a defined period (typically 10-30 minutes). If the buyer completes purchase, the reservation converts to an allocation. If the buyer abandons, the reservation expires and the stock returns to the available pool.

The reservation model produces strong guarantees against overselling at the cost of potential undersells (reserved stock is invisible to other buyers even if the original buyer never completes). It is the right model for high-demand scenarios where overselling would create severe customer impact — flash sales, limited-edition products, B2B contracts where commitment is sensitive.

Allocation model. Stock is allocated only when an order is confirmed. Up until the order is placed, all available stock is visible to all buyers. Two buyers can each see the same unit as available; the first to place an order gets it, the second is informed at order confirmation that the unit is no longer available.

The allocation model maximises stock visibility (no stock is hidden behind reservations) at the cost of weaker overselling guarantees in concentrated-demand scenarios. It is the right model for catalogues with high stock depth where contention is rare.

Hybrid models. Real composable commerce systems frequently use both. High-velocity products use reservation, deep-stock products use allocation. The choice is configured per product or per category, and the integration logic must support both modes cleanly.

The decision is not abstractly architectural — it has commercial consequences. Get it right per product class, and overselling and underselling are both rare. Get it wrong, and you trade one failure mode for another.

The Event Flow

A working composable commerce inventory orchestration has a clear event flow. The canonical shape:

WMS / ERP                 Event Bus                Composable Stack
─────────                 ─────────                ───────────────────
Stock receipt   ────►   stock.received   ────►   OMS  → Elastic Path catalogue
Stock pick      ────►   stock.picked     ────►   OMS
Stock count     ────►   stock.adjusted   ────►   OMS  → Elastic Path catalogue

Storefront                                       OMS / WMS
──────────                                       ──────────
Cart add        ────►   cart.item.added  ────►   OMS (reservation if applicable)
Order placed    ────►   order.placed     ────►   OMS  → ERP
                                                 OMS  → WMS (pick request)

Order updated   ────►   order.updated    ────►   ERP / WMS
Order shipped   ────►   order.shipped    ────►   ERP / Storefront notification

A few principles worth highlighting.

One canonical event topology. The systems publish their own events (stock receipts from WMS, order placement from storefront), which are translated into a canonical event vocabulary that all consuming systems understand. Composable architectures that allow each system to consume the others’ raw event formats produce tightly coupled integration that fails as systems are replaced.

Idempotent processing everywhere. Events are delivered at-least-once in any realistic distributed system. Every consumer must be able to handle a duplicate event without producing a duplicate effect. The pattern is consumer-side deduplication keyed on event ID and a content hash, with the deduplication window sized to the maximum expected delivery delay.

Outbox pattern at producers. When a storefront writes an order to its own database, the corresponding event is written in the same transaction to an outbox table. A separate process publishes the outbox events to the bus. This guarantees that no order is recorded without a corresponding event, and no event is published for an order that was rolled back. Without this pattern, the bus and the database silently diverge under load.

Compensation events for reversals. When an order is cancelled after stock has been allocated, a compensating event releases the stock. The systems must support the full lifecycle — placement, modification, cancellation — through events, not just the happy-path forward direction.

Bus reliability matters. The choice of event bus is consequential. Apache Kafka, Azure Event Hubs, Amazon SNS+SQS, and similar systems offer the durability and ordering properties that composable commerce inventory requires. Lightweight pub/sub (Redis pub/sub, basic webhooks) does not. For all but the smallest deployments, invest in proper event infrastructure.

ATP: Available-to-Promise Calculations

Available-to-Promise (ATP) is the calculation that determines what the storefront shows to the buyer as available. It is conceptually simple but operationally subtle.

A naïve ATP is “current physical stock minus current allocations.” A useful ATP includes:

• Physical stock at each warehouse. Multi-warehouse setups must compute ATP per warehouse and combine.
• Inbound stock with arrival dates. Stock that has been ordered from suppliers but not yet received, with a date the customer can reasonably promise.
• Reserved stock minus expired reservations. The reservation pool reduces ATP, but reservations expire and the calculation must reflect this.
• Allocations to confirmed orders. Stock committed to fulfil existing orders.
• Hold reasons. Stock in quality-hold, returned-to-supplier, or otherwise unavailable.
• Safety stock thresholds. Minimum stock levels reserved against operational uncertainty.

The ATP calculation runs on demand for each product page view and search result, which means it must be fast. The pattern that works is a denormalised ATP cache in the storefront’s read store, updated by event-driven invalidation. When a stock event arrives, the affected products’ ATP is recalculated and the cache is updated. The storefront reads from the cache; cache writes are bounded by event volume, not by storefront traffic.

For multi-warehouse setups with split fulfilment, ATP also drives fulfilment routing — which warehouse fulfils which line of which order. This decision logic typically lives in the OMS and consumes the same ATP signals.

Distributed Order Management

The Order Management System is the linchpin of composable commerce inventory orchestration. Its responsibilities:

• Receive orders from the storefront and validate them against current inventory state.
• Allocate stock across warehouses and against incoming supply where appropriate.
• Coordinate fulfilment — pick and pack instructions to warehouses, shipping label requests to carriers, status updates back to the storefront.
• Handle exceptions — split shipments when single-warehouse fulfilment is impossible, backorders when supply lags demand, returns and reverse logistics.
• Maintain order state as the source of truth for order lifecycle.

Elastic Path itself is not an OMS. It is the catalogue, customer, and pricing layer. Composable architectures pair Elastic Path with a dedicated OMS — IBM Sterling Order Management, Manhattan Active Omni, Fluent Commerce, or built-in capabilities from ERP suites — and the OMS handles the order orchestration the catalogue does not.

The integration boundary between Elastic Path and the OMS is one of the most consequential design decisions in a composable build. Patterns that work:

• Order placement events from Elastic Path to the OMS. When an order is placed, Elastic Path publishes an event; the OMS consumes it and takes ownership of the order from there.
• Order state events from the OMS to Elastic Path. As the OMS updates order state, it publishes events that Elastic Path consumes for buyer-facing order tracking.
• Inventory state events from the OMS to Elastic Path. ATP updates flow from the OMS to Elastic Path’s catalogue layer for storefront display.
• Customer state events from Elastic Path to the OMS. Customer changes (account hierarchy updates, contract changes) flow to the OMS for fulfilment context.

The bidirectional flow must be designed deliberately. Each event must have a clear producer, a clear set of consumers, and a clear semantic.

ERP Integration Patterns

Behind the OMS sits the ERP. ERPs hold financial inventory — accounting state, supplier relationships, valuation. ERP integration is the deepest part of the composable commerce stack and the part where engineering rigour pays off most.

Common ERPs in the composable commerce context:

SAP S/4HANA and SAP ECC. SAP integration uses BAPIs, IDocs, or modern OData services depending on version and edition. SAP’s stock model is rich (storage locations, batches, special stock indicators) and the integration must respect this richness rather than flattening it.

Microsoft Dynamics 365 Finance & Supply Chain. Integration uses the Dynamics OData API and event-based triggers. Dynamics is generally easier to integrate with composable commerce than SAP, partly because the Microsoft Graph and Power Platform tooling make eventing more tractable.

Oracle NetSuite. SuiteScript and SuiteTalk APIs are the primary integration surface. NetSuite’s inventory model is more transactional and less rich than SAP, which simplifies integration but requires careful handling of multi-warehouse and multi-currency scenarios.

Oracle Fusion ERP Cloud. REST and SOAP APIs against the Oracle Fusion Inventory Management module.

Mid-market ERPs (Sage, Intacct, Acumatica). Generally simpler integration surfaces, fewer concurrent users, lighter throughput requirements.

The integration patterns are largely common across ERPs:

• Master data sync. Products, suppliers, warehouses synchronised between Elastic Path’s catalogue layer and the ERP. Typically a one-way sync from ERP to Elastic Path for product master data, with the ERP as the source of truth.
• Inventory state events. Stock position updates flow from ERP (or the WMS, depending on which system holds physical stock authoritatively) into the composable stack.
• Order events. Confirmed orders flow from the OMS to the ERP for invoicing, revenue recognition, and supplier-side fulfilment.
• Reconciliation jobs. Daily or hourly reconciliation that compares stock positions across systems and flags drift. This is the safety net that catches errors the event flow misses.

The reconciliation job is unglamorous engineering and frequently underinvested in. It is also the thing that lets you sleep at night. Build it.

Patterns for Specific Failure Modes

A few patterns that address common failure modes:

Idempotent order processing. Every order operation includes a unique idempotency key. Re-submission of the same order produces the same result — not a duplicate. This protects against the inevitable retry-during-degraded-network scenarios.

Saga pattern for cross-system transactions. When an order placement spans multiple systems (storefront → OMS → ERP → payment), use the saga pattern: each step is committable independently, with explicit compensation on failure. Avoid the “distributed transaction” temptation; sagas are simpler to operate at scale.

Event sourcing for order history. Storing the full event history of an order — not just its current state — makes order disputes, fulfilment debugging, and audit obligations dramatically more tractable. The storage cost is small; the operational benefit is large.

Inventory hold timeouts. Reservations must expire. Allocations made during incomplete checkouts must release. The timeout values are tunable per product class but their existence is non-negotiable.

Backpressure on bus producers. When the bus is congested, producers must back off rather than blindly publishing. Without backpressure, congestion compounds and produces system-wide degradation.

Dead-letter queues with operator action. Events that cannot be processed must be parked, not dropped. A working operator workflow for inspecting and replaying dead-lettered events is part of the production posture, not an after-the-fact addition.

Storefront-Side Considerations

The buyer-facing storefront depends on the inventory orchestration but has its own responsibilities.

Cache invalidation. Storefront product pages cache ATP for performance. When inventory state changes, the cache must invalidate quickly enough that buyers see fresh information. CDN-level caching with event-driven purge, or origin-side caching with short TTLs and request collapsing, are the standard patterns. Pure time-based caching produces stale displays that confuse buyers.

Out-of-stock handling. When a product is out of stock, the storefront should offer alternatives, indicate expected restock dates, and capture wait-list interest. These behaviours depend on the inventory orchestration providing the relevant data — restock dates from the ERP, alternatives from the catalogue and recommendation engine.

Last-step availability checks. A product that was available when added to cart may not be available at checkout completion. Re-checking ATP at the order placement step (not just at cart add) is a pragmatic guard against the inevitable race conditions.

Buyer-facing communication on backorders. When the system accepts an order against incoming supply rather than current stock, the buyer must understand. Clear UI patterns for “available in 2 weeks” or “ships when in stock” reduce post-order surprises.

Where McKenna Helps

McKenna Consultants delivers composable commerce inventory orchestration as part of broader Elastic Path engagements. The typical engagement shape:

Architectural design. Event topology design, OMS selection support (where applicable), ERP integration architecture, ATP model design. Output: a documented integration architecture with the systems, events, and ownership boundaries.

Implementation. Build of the event integration layer, OMS-Elastic Path integration, ERP integration, ATP cache, reconciliation jobs. Output: a working composable commerce stack with real-time inventory orchestration.

Production readiness. Load testing, race-condition exercise, dead-letter queue operability, runbook development. Output: a production-deployable system with documented operational procedures.

Operational excellence. Ongoing inventory accuracy monitoring, drift detection, and tuning. Often delivered as a managed service alongside an Elastic Path implementation.

McKenna is a UK-based Elastic Path consultancy. Our team has delivered B2B composable commerce builds across manufacturing, distribution, industrial technology, and professional services — including the inventory orchestration that those builds depend on. If your organisation is designing or rebuilding the inventory backbone behind a composable commerce stack, contact us to discuss the engagement.