Stock synchronisation across an e-commerce group's warehouses

The group ran three storefronts on different platforms drawing from four warehouses, and stock levels were synchronised by scheduled exports every fifteen minutes. During promotions that window was long enough to oversell popular items, and the resulting cancellations were both expensive and the top driver of negative reviews. Warehouse staff also had no visibility into which storefront had committed stock they were about to ship, so picking lists sometimes conflicted. They wanted a single view of availability that all three storefronts and all four warehouses respected.

Contract backend engineer, six months, brought in specifically for this. I worked alongside their two in-house developers and reported to the head of operations rather than to engineering, which shaped a lot of the priorities.

I built the availability service: the reservation model, the per-warehouse allocation rules, and the webhooks each storefront calls to hold and release stock. I owned the reconciliation against warehouse counts, including the daily drift report that goes to each warehouse manager. I wrote the storefront adapters for two of the three platforms and reviewed the third. The oversell alerting and the runbook for manual correction are mine.

I modelled availability as reservations with expiry rather than as a running count, so an abandoned cart releases stock on its own and no cleanup job is load-bearing. The simpler decrement-a-counter approach was what they had asked for, and I spent a meeting arguing that it makes every failure mode a permanent one. I also chose to let the service be authoritative only for availability, never for the warehouse's own record — it reads counts and never writes them — because the warehouse system was old, fragile, and the operations team's trust in it was the thing holding everything together. For the transport I used simple HTTP webhooks with retries rather than a queue, since the three storefronts had wildly different reliability and per-target retry policy was easier to reason about.

One storefront platform was hosted and could only be integrated through its published API, which had a rate limit that made bulk updates slow — that alone shaped the fan-out design. I had no ability to change the warehouse system at all. The promotional calendar was fixed months ahead, so the whole thing had to be live and proven before a particular sale weekend, and it was not negotiable.

Overselling on promotional items went from roughly 2.3 percent of orders during the previous big sale to under 0.2 percent on the one after launch, measured on the same product set. Availability propagation went from up to fifteen minutes to about two seconds. The daily drift report turned up a warehouse whose counts had been quietly wrong for months, which was not what anyone was looking for but was worth the project on its own.

Their two in-house developers took over the third storefront adapter and now own the service. The head of operations defined the allocation rules, which encode a lot of knowledge about which warehouse ships to which region cheapest. A warehouse supervisor walked me through a full picking shift, which changed the drift report's format entirely.