Multi-warehouse inventory sync without nightly batch jobs.

A distributor of automotive parts in Mumbai oversold a 28,000 rupee high-margin SKU on a Tuesday morning in early 2024. The product had moved from the Pune warehouse the previous afternoon, but the WooCommerce front-end was still showing it as available because the inventory sync ran every night at 2 AM. Two customers checked out within four minutes of each other. Both received the order confirmation. One received the part. The other received a refund, a generic apology email, and a six-month silence before placing another order.

The founder added the loss up. One unit. One customer relationship damaged. One team member's afternoon spent on customer service for a problem the system should have prevented. Multiply by the number of times this happens in a quarter across a 1,500-SKU catalogue running across three or four warehouses, and the cost of nightly batch sync becomes a six-figure annual line item that nobody on the team had named.

This essay is about why nightly sync is structurally wrong for multi-warehouse distribution and what the right architecture looks like.

Why nightly batch sync exists at all

The pattern of nightly inventory sync exists because the first generation of ecommerce-plus-back-office integrations were built that way. The storefront ran on one platform. The inventory lived in another (Tally, a desktop ERP, a spreadsheet). A script ran overnight, pulled inventory levels from the back office, and updated the storefront. The script ran nightly because daily exports were the only interface the back-office tools exposed.

The pattern worked when storefront volume was low and warehouse activity was concentrated in business hours. Overnight, nothing moved. The 2 AM sync caught up. By 9 AM, the storefront reflected the warehouse.

The pattern fails as soon as the storefront runs 24 hours and the warehouse has activity across a workday that overlaps the storefront. Both conditions are true for any serious Indian distributor today. Customers check out on Sunday evening. Warehouse staff pick orders on weekday afternoons. The two activities collide in a way nightly sync cannot reconcile.

What "overselling" actually costs

A single oversell event has direct cost and indirect cost. The direct cost is a refund, a lost order, and the team time to process the cancellation. The indirect cost is the customer's lost trust and the future orders that customer would have placed.

For a trade customer, the loss compounds. Trade buyers reorder regularly. A trade buyer who experiences a stockout-after-order incident migrates a portion of their wallet to a competitor for the next three to six months. The team rarely notices, because the customer does not call to complain. They simply place fewer orders.

Estimating the indirect cost is hard. A conservative model assigns 4,000 to 8,000 rupees of lost lifetime value per oversell incident, on top of the direct cost. A distributor running nightly sync across four warehouses with active 24-hour storefront traffic typically produces 20 to 40 oversell incidents per quarter. The annualised cost lands between 4 and 12 lakh rupees, before anyone has costed the team time.

What event-driven sync actually looks like

Event-driven sync means the storefront's view of inventory updates the moment a warehouse transaction happens, not on a schedule.

The architecture is straightforward in description and disciplined in execution. Every inventory-moving event in the back office publishes a message: SKU moved, quantity changed, warehouse identified, timestamp recorded. The storefront subscribes to these messages and updates its inventory cache within seconds. A sale on the storefront publishes its own message back to the inventory system, which deducts from the appropriate warehouse based on the routing rule.

The transport can be a message queue, a webhook, or a real-time database push. For distributors at the 5 to 50 crore revenue scale, a properly tuned PostgreSQL with notification triggers, or a lightweight message broker, is more than enough. The architecture does not require Kubernetes or microservices. It requires a back-office system designed to emit events and a storefront designed to consume them.

The architecture we built for AKSD's WooCommerce and custom ERP integration uses this pattern. Inventory state lives in PostgreSQL inside the custom ERP. WooCommerce subscribes to inventory updates via webhook. The storefront's view of stock is never more than a few seconds behind warehouse reality. The same pattern, in a simpler form, underpins the inventory layer we built for Car Seat Wala's ERP.

What a single source of truth requires

Event-driven sync works only when one system holds the authoritative inventory state. If WooCommerce holds one number, Tally holds another, and a warehouse Excel holds a third, no sync architecture can reconcile them.

The discipline is to designate the back-office system as the source of truth and to remove every parallel inventory record. The team enters stock movements in one place. Every other view (the storefront, the dealer portal, the founder's dashboard) reads from that one place. The cost of that discipline is one round of cultural work with the warehouse team, which lasts about three weeks. The benefit is that inventory questions have one answer.

This is the same structural property we wrote about in our piece on decision infrastructure for founder-led businesses. One operational fact, one canonical location, one answer.

Why this is not "real-time everything"

Event-driven sync is not the same as making every system real-time. The accounting integration with Tally can still run in batches. The reporting layer can still aggregate hourly. The vendor purchase orders can still generate end-of-day. The discipline is specifically about the inventory-availability signal that the storefront shows to a customer about to commit to a purchase.

The reason to be selective is that real-time architecture has cost. Every event-driven path needs error handling, retry logic, and observability. Applying real-time discipline everywhere produces a system that is expensive to maintain. Applying it where it matters (inventory at point of purchase) produces a system that costs roughly the same as a batch architecture and prevents the oversell scenario the firm is paying for every quarter.

The migration path from nightly to event-driven

A distributor running nightly sync today does not need to rebuild the entire stack. The migration path has three stages.

The first stage is inventory consolidation. Identify the authoritative source. Retire the parallel records. The team enters stock movements in one place. This stage takes three to six weeks and is mostly process work.

The second stage is the event emission layer. The back-office system gets a small extension that publishes inventory changes as they happen. The development effort is one to two weeks for a typical distributor's catalogue.

The third stage is the storefront subscription. The storefront updates its inventory cache from the event stream rather than from a nightly script. The development effort depends on the storefront platform. WooCommerce takes one to two weeks. Shopify requires app or middleware work. Custom storefronts take a week.

Total migration time is six to ten weeks. Total cost is a fraction of one year's worth of oversell incidents.

A founder running a distribution business should ask one question of their current stack. If a unit ships out of the Pune warehouse at 3:47 PM on a Wednesday, when does the storefront know about it? If the answer is "tomorrow morning" or "after the script runs", the architecture is leaking margin every week. The fix is bounded. The benefit is continuous. The path to internal systems that hold inventory truth is well-trodden.

Start a Conversation.