Inventory management is unglamorous.
Nobody writes dev.to posts about stock counts. No engineering blog celebrates the moment inventory sync worked correctly. No conference talk opens with "let me tell you about our polling architecture."
And yet — for every ecommerce seller running across multiple channels simultaneously, inventory sync is the most business-critical piece of infrastructure they have. And most of it is built wrong.
Here's what we built at Nventory, why we built it differently, and what the architecture actually looks like.

The problem we kept seeing
Every multichannel seller we talked to had the same story. Flash sale turns into a crisis. Oversells they couldn't explain. Marketplace accounts flagged for cancellations that came from nowhere.
All traceable back to one thing — a sync interval.
javascript// What most inventory tools are doing under the hood
setInterval(async () => {
const stock = await getSourceOfTruth();
await syncToAllChannels(stock);
}, 15 * 60 * 1000); // every 15 minutes

// At 500 orders/day this creates:
const windowsPerDay = (24 * 60) / 15; // 96
const ordersPerWindow = 500 / windowsPerDay; // ~5.2
// Each window: 5+ orders processed against potentially stale stock
// During a flash sale at 10x velocity: 52 orders per window
// Result: predictable, preventable oversells
96 windows per day where channels disagree about stock. At flash sale velocity — catastrophic. And completely avoidable.

The architectural decision
We built Nventory around event-driven propagation from day one.
javascript// Every stock mutation fires an immediate event
orderEventBus.on('order.confirmed', async (event) => {
const { sku, qty, channel, orderId } = event;

// Idempotency — handle retries safely
if (await idempotencyStore.exists(orderId)) return;

// Optimistic locking — handle concurrent orders safely
const result = await inventory.decrementWithLock(sku, qty, {
expectedVersion: event.stockVersion
});

if (!result.success) {
await oversellPrevention.handle(event);
return;
}

// Propagate immediately to every connected channel
await Promise.all(
connectedChannels
.filter(ch => ch.id !== channel)
.map(ch => ch.updateInventory(sku, result.newQty))
);

await Promise.all([
idempotencyStore.mark(orderId),
auditLog.record({ ...event, result, timestamp: Date.now() })
]);
});
Three decisions worth explaining:
Idempotency keys — retry logic is inevitable at volume. Without idempotency, retries create duplicate decrements that corrupt stock counts silently. Every mutation gets a key. Every retry checks it first.
Optimistic locking — concurrent orders from different channels hitting the same SKU need to resolve against the same stock count. Without locking, race conditions produce oversells even with event-driven sync. We use version-based optimistic locking rather than pessimistic locks to avoid throughput bottlenecks.

Audit trail - every stock mutation logged with timestamp, source channel, quantity, resulting count, and propagation status. When something goes wrong and it will — the entire history is traceable in seconds rather than reconstructed from logs.

The propagation layer
Getting every connected channel updated in under 5 seconds across 40+ integrations requires careful management of the propagation layer.
javascriptclass PropagationManager {
constructor(channels, metrics) {
this.channels = channels;
this.metrics = metrics;
this.deadLetterQueue = new DeadLetterQueue();
}

async propagate(mutation) {
const { sku, newQty, sourceChannel } = mutation;
const start = performance.now();

const results = await Promise.allSettled(
  this.channels
    .filter(ch => ch.id !== sourceChannel)
    .map(async ch => {
      try {
        await ch.updateInventory(sku, newQty);
        this.metrics.record('propagation_success', { channel: ch.id });
      } catch (error) {
        // Failed propagation goes to dead letter queue
        // Never silently dropped
        await this.deadLetterQueue.push({
          mutation,
          channel: ch.id,
          error: error.message,
          retryAt: Date.now() + this.backoffMs(ch.failureCount)
        });
        this.metrics.record('propagation_failure', { channel: ch.id });
      }
    })
);

this.metrics.record('propagation_duration_ms', {
  value: performance.now() - start,
  channelCount: this.channels.length - 1
});

return results;

}

backoffMs(failureCount) {
return Math.min(1000 * Math.pow(2, failureCount), 30000);
}
}
The dead letter queue is the piece most homegrown implementations skip. Failed propagations that get silently dropped create invisible stock discrepancies — the worst kind, because they accumulate without triggering any alert. Every failed propagation goes to DLQ. Every DLQ item retries with exponential backoff. Nothing gets silently lost.

What we built on top
The sync architecture is the foundation. On top of it:
AI automation sellers describe workflows in plain English, the system builds and executes trigger-condition-action logic automatically. No code.

Smart order routing — every order evaluated against proximity, cost, speed, and stock availability across FBA, 3PLs, and owned locations simultaneously. Routing decision made in milliseconds.

Multi-carrier shipping, real-time rate shopping across 100+ carriers per order. Labels in batch. Tracking syncs back to every channel automatically.

WhatsApp Business orders through conversations entering the same fulfilment queue as every other channel. Inventory updates in real time.
All of it built on the same event-driven foundation — every action triggering downstream events that propagate correctly across every connected system.

The honest reflection
Inventory management is unglamorous. Nobody congratulates you when it works. The engineering is invisible by design.
But for a seller who just ran their best flash sale zero oversells, zero chaos, zero Sunday morning spreadsheets - the infrastructure underneath it is the reason everything worked.
That's what we're building at Nventory.

Worth exploring if you're working on multichannel ecommerce infrastructure: nventory.io/us