Near real-time stock availability, without rewriting the e-commerce

One of Italy's leading suppliers of materials for the footwear industry, serving cobblers and shoe manufacturers, came to us to rebuild their e-commerce. After looking at it, we told them they did not need to. The real problem was a single capability, because stock availability on the site refreshed only twice a day and was tied to an ERP no one could replace. We treated it as a legacy evolution rather than a rewrite, so we left the existing platform untouched, brought availability down to milliseconds, and delivered it for roughly 70% less than the full rebuild that had been on the table.

Context

The client is one of Italy's leading suppliers of materials for the footwear industry, working with both independent cobblers and shoe manufacturers. Their catalog moves constantly, because stock comes in and out of the warehouses throughout the day, and the website is where customers check what is available before they order.

They reached out with a clear request, which was to rewrite the e-commerce from scratch. The reason behind that request, though, was narrower than the request itself. The stock figures shown on the site only refreshed twice a day, so a customer could see a material as available that had in fact been gone for hours. What they really wanted was near real-time alignment between what was in the warehouses and what the site showed.

They had already been down this road. Other companies had looked at it, and at least one had tried before and not managed to solve it. The blocker was always the same, because the business ran on an ERP that could not be replaced, or could only be replaced at a cost that made no sense for the problem at hand.

The challenge

The constraint was the ERP, not the website. Stock lived inside an ERP running on SQL Server, and that system was load-bearing for the whole business, so swapping it out was off the table. Every previous attempt had run into the same wall, which was how to get continuous, trustworthy stock data out of a system you are not allowed to touch and into a site that is currently reading it twice a day.

Faced with that wall, the conclusion others had reached was to rebuild around it, but our analysis pointed the other way. The rest of the e-commerce was straightforward and doing its job, so rewriting it would have been expensive, slow, and beside the point, and it would not have moved the one number that mattered. This was really a legacy modernization problem in disguise, because the actual work was a single, well-defined integration. We needed to get stock movements from the ERP to the site continuously and reliably, without replacing the ERP and without rebuilding a platform that already worked.

When we heard that the sticking point was near real-time stock sync, we smiled and looked at each other, because it is one of the things we have solved most often, including in environments with heavy, constant warehouse movement.

Approach

Reframing the brief. The first thing we did was tell the client they did not need a rewrite. The functionality they had was fine, and spending a full rebuild's worth of time and budget would not have made stock any fresher, so we scoped the work down to the part that actually mattered.

Integrating with the ERP, safely. Working together with the vendor that had built the ERP, we got what we needed to read directly from the SQL Server database, in a way that respected the system without putting load or risk on it.

Decoupling the site with a dedicated read store. Until then, the website connected directly to their main database over a VPN, so the storefront was effectively wired into the warehouse system and shared its load and its fragility. We changed that completely. We built components that capture every stock movement and, through a distributed messaging system, replicate it into a separate read store dedicated solely to the e-commerce. The site was then connected directly to this read store and nothing else. The result is full decoupling, because the storefront no longer touches the production database at all, the ERP keeps doing its job without extra load, and the site always reads from a store that is purpose-built to serve it fast.

Resilience by design. Deduplication and retry logic make sure every movement is tracked exactly once and nothing is lost. If the link between the warehouses and the site goes down, stock changes accumulate and are then processed afterwards in parallel and very quickly, so the moment the connection is back the site catches up almost immediately rather than drifting out of date.

Headroom for growth. In optimal conditions, availability on the site updates in the order of milliseconds. That is well within what the current traffic needs, with room to spare if the site grows substantially in the future.

Results

• Stock availability on the site went from refreshing twice a day to near real time, in the order of milliseconds in optimal conditions.
• 95% fewer orders cancelled or amended because an item turned out to be out of stock, since customers now buy against what is actually on the shelf rather than yesterday's picture.
• Roughly 70% lower cost than the full e-commerce rewrite that had been proposed. Treating it as a legacy evolution rather than a rebuild meant the client paid for the one capability they needed, not for replacing a platform that already worked.
• A problem a previous vendor could not crack, solved without replacing the ERP. The system everyone was afraid to touch stayed exactly where it was.
• A pipeline that holds up under heavy warehouse movement and keeps working through connection failures, thanks to deduplication, retries, and parallel catch-up.
• A foundation that scales with traffic, so the same approach keeps working as the business grows.

What we learned

The brief is not always the problem. The client asked for a rewrite, but the real need was a single capability. The hardest and most valuable part of the engagement was not the messaging architecture, it was the discipline not to sell the bigger project. Good legacy modernization is often about evolution rather than replacement, so by isolating the one real constraint, which was stock sync from an ERP that could not be replaced, we delivered exactly the outcome they came for, for a fraction of the cost, and left everything that already worked alone.