Real-Time Inventory Sync for Headless Commerce: NetSuite, Shopify, and the Oversell Problem (2026)

The moment you go headless and put an ERP behind the storefront, inventory stops being one number and becomes several systems arguing about a number. NetSuite thinks it holds the truth. Shopify serves a cached count to the storefront. A marketplace polls on its own schedule. A retail POS decrements a fourth copy at the register. Each is internally consistent and none of them agree at any given instant, and in the gaps between their update clocks two customers buy the last unit. Overselling in this setup is not bad luck; it is the expected result of treating a distributed count as if it were authoritative. Here is the sync architecture that keeps the count honest, and the trade-offs that decide how far you have to go.

Pick One System of Record, Then Enforce It

The first decision, and the one teams most often skip, is declaring which system owns the inventory number. Not which system displays it, which system is allowed to be right when two of them disagree. In a stack with NetSuite as the ERP, the honest answer is usually NetSuite, because it is where receiving, fulfillment, returns, and adjustments actually happen, so it sees every event that changes real stock. The storefront and every channel then become read replicas of that number, allowed to cache it and decrement optimistically but never to be the tiebreaker.

The failure mode to avoid is a stack with no declared owner, where Shopify and NetSuite both write inventory and a bidirectional sync tries to reconcile them. That design guarantees a class of conflict that has no correct resolution, because when the two disagree there is no rule for which wins, only a last write that clobbers the other. Choosing NetSuite as the single source and making Shopify and the channels one directional consumers of it removes the ambiguity, at the cost of accepting that the storefront's number is always slightly behind the truth. That lag is the real problem to engineer around, and it is more tractable than a reconciliation with no ground truth. We go deeper on the broader integration surface in the NetSuite and Shopify integration patterns writeup, and on whether NetSuite should be your record of truth at all in the NetSuite versus Acumatica comparison.

Push, Do Not Poll

Once NetSuite owns the number, the question is how the storefront and channels learn about changes. The tempting default is polling: every few minutes, ask NetSuite for current levels and update everyone. Polling is simple and it is wrong at any real scale, because it forces a trade-off between freshness and load that has no good setting. Poll often enough to catch changes quickly and you hammer the ERP with queries most of which return nothing new; poll rarely enough to spare the ERP and your storefront count goes stale exactly when a fast selling item needs it fresh.

Event driven sync inverts this. NetSuite emits a change event when a level actually moves, that event lands on a queue, and a worker fans it out to Shopify and the other channels. Now updates propagate in seconds instead of minutes, the ERP is queried only when something changed, and the load scales with the rate of real inventory movement rather than with your polling frequency. The cost is that you now depend on delivery reliability: a dropped event means a channel silently holds a stale count until the next full reconciliation, which is why event sync needs an idempotent consumer and a periodic full sweep as a backstop rather than as the primary mechanism. We cover the delivery guarantees this requires in the webhook reliability writeup.

Sync approach	Freshness	ERP load	Fails how
Frequent polling	Minutes, tunable	High, mostly empty queries	Stale during spikes, ERP strain
Infrequent polling	Poor	Low	Oversell on fast movers
Event driven push	Seconds	Scales with real change	Dropped event, needs reconciliation backstop
Event push plus nightly sweep	Seconds, self healing	Low steady, one full pass	Best general answer

The Safety Buffer Is a Strategy, Not a Hack

No sync is instantaneous, so between the moment NetSuite's count drops and the moment every channel reflects it, there is a window where the storefront will happily sell stock that is already gone. You cannot close that window to zero, so the practical move is to not sell all the way down to it. A safety buffer publishes a number lower than the true count, holding back a few units per channel so that the sync lag is absorbed by slack rather than by an oversell.

The buffer is not a fixed number; it should scale with how fast an item sells and how many channels compete for it. A slow moving item sold on one channel needs almost no buffer, because the lag is unlikely to overlap two purchases. A fast moving item sold across four channels needs a real one, because concurrent buyers on different channels are exactly the scenario the buffer exists for. Setting it well is a margin decision: too small and you oversell and eat the cost of cancellations and disappointed customers, too large and you strand sellable inventory and lose the sale to a stockout you manufactured.

// Publish a buffered count per channel, sized to velocity and channel count.
// This runs when a NetSuite inventory event arrives, before fanning out.
function publishableStock(trueCount, dailyVelocity, activeChannels) {
  // Reserve roughly the units likely to sell during the worst case sync lag,
  // scaled up when several channels can each take a unit concurrently.
  const lagHours = 0.25;                         // worst case propagation delay
  const perChannelRisk = (dailyVelocity / 24) * lagHours;
  const buffer = Math.ceil(perChannelRisk * Math.max(activeChannels, 1));
  return Math.max(trueCount - buffer, 0);         // never publish a negative
}

// Fast mover on many channels -> larger buffer. Slow single channel item -> ~0.

Reservations Turn the Last Unit Race Into a Queue

The buffer reduces oversell risk but does not eliminate the sharpest case, which is two customers reaching checkout for the genuinely last unit within the same second. A buffer cannot help here because the buffer is already spent; this is a concurrency problem and it needs a concurrency answer. A reservation pattern provides one: when a customer enters checkout, the system places a short lived hold on the unit, decrementing available stock immediately and locally, and only converts the hold to a committed decrement when payment settles. If payment fails or the hold expires, the unit returns to available.

This changes the shape of the problem. Instead of two checkouts both reading available stock as one and both proceeding, the first to acquire the hold gets it and the second sees zero available and is told the item just sold, which is a far better experience than a confirmation email followed by a cancellation. The reservation lives at the layer that fronts checkout, close to the customer and fast to read and write, and it reconciles to NetSuite asynchronously rather than asking the ERP to arbitrate a race it updates too slowly to win. The trade-off is added state and complexity: holds have to expire reliably, expired holds have to release, and the reservation store becomes a component you have to run and monitor. It is worth it for high demand drops and limited stock items and overkill for a catalog of deep stock slow movers.

Item profile	Buffer alone	Buffer plus reservations
Deep stock, slow moving	Sufficient	Unnecessary complexity
Fast moving, multi channel	Reduces but does not eliminate oversell	Recommended
Limited drops, high demand	Will oversell the last units	Required
Single unit or made to order	Risky	Reservation is the only safe design

When This Applies to Your Stack

If you run or are planning a headless build with an ERP behind it, start by naming the system of record out loud and making every other system a read consumer of it, because a stack with two writers and no tiebreaker will oversell no matter how good the rest of your sync is. Move from polling to event driven push so freshness stops fighting ERP load, and add a nightly full reconciliation as a backstop rather than a crutch. Size a safety buffer per item against velocity and channel count instead of picking one global number, and reach for reservations specifically on the fast moving, limited, high demand items where the last unit race is real, not across a catalog that does not need it. The goal is not a perfect count, which is unattainable in a distributed stack, but a count that is honest enough that the gap never reaches a customer.

If your team is building or fixing inventory sync across NetSuite, Shopify, and a set of channels and wants the ownership model, the event pipeline, the buffer math, and the reservation layer designed against your actual order volume and margins, Contra Collective does headless commerce and platform migration work that treats the ERP, the storefront, and every channel as one inventory system rather than four that occasionally agree.

FAQ

Why does headless commerce oversell more than a packaged platform? A packaged platform owns and decrements one inventory number and hides the brief settling window. A headless stack adds an ERP as the record of truth plus other channels, so several systems each hold a copy of the count and update on different clocks. In the gaps between those clocks, two buyers can purchase the same last unit, which is the default outcome of treating a distributed count as authoritative rather than the exception.

Which system should own the inventory number? Usually the ERP, NetSuite in a typical stack, because that is where receiving, fulfillment, returns, and adjustments happen, so it observes every event that changes real stock. The storefront and channels become one directional read consumers that cache and optimistically decrement but never act as the tiebreaker. A stack where two systems both write inventory produces conflicts with no correct resolution.

Should inventory sync use polling or webhooks? Event driven push, backed by a periodic full reconciliation. Polling forces a bad trade-off between freshness and ERP load: poll often and you hammer the ERP with mostly empty queries, poll rarely and fast movers go stale. An event that fires when a level actually changes propagates in seconds and scales with real movement, as long as you handle dropped events with an idempotent consumer and a nightly sweep.

How big should the inventory safety buffer be? It should scale with sales velocity and channel count, not be one global number. A slow item on a single channel needs almost none; a fast item across several channels needs a real buffer because concurrent cross channel purchases are exactly the risk. Set it as a margin decision: too small oversells and forces cancellations, too large strands sellable stock and manufactures stockouts.

When do I need a reservation system instead of just a buffer? When the last unit race is real: fast moving items, limited drops, high demand releases, and single unit or made to order products. A buffer cannot resolve two checkouts hitting the genuinely last unit in the same second, but a short lived hold placed at checkout can, by granting the unit to the first and telling the second it just sold. For deep stock slow movers, reservations are unnecessary complexity.