Catalog recovery
Product and category changes could reach the search index after the interrupted update path was restored.
E-commerce · Wholesale operations
Getting wholesale products from the back office to the buyer
Shinetech restored a broken catalog-indexing path, refined warehouse receiving rules, and improved reporting within an operating wholesale commerce platform.
The business context
Saving a product was not the same as making it available to buy.
For a fashion and accessories wholesaler, the online catalog is where retailers discover merchandise for their own stores. Product collections, available stock, and order fulfillment are closely connected. An item can exist in the administration system yet still be missing from the buying experience if a downstream update fails.
The client already ran its business on a custom commerce platform. Storefronts, administration screens, background jobs, and related sites shared core code and data. Shinetech’s work focused on keeping that established operation usable while improving the parts that were creating manual intervention: product discovery, receiving, and large operational exports.
From catalog record to warehouse task
A product record ties a catalog update to its search status and receiving context. Product images, SKUs, quantities, and times are invented; this reconstruction illustrates the workflow, not the client’s interface. View full-size interface (new tab)
The operating challenge
The visible symptom was in the storefront. The cause was elsewhere.
Product and category changes stopped reaching the storefront because the search index was no longer updating successfully. The failure crossed several layers. A deleted log file was still held open by a running process, so deleting it had not released the occupied disk space. The disk filled, indexing failed, and a scheduled restart had also been ineffective because of its execution environment.
Fixing the edit screen would not have repaired this chain. The team traced the path from saved product data through the background process and search service, addressed the storage and restart problems, and restored indexing. The business check was whether an updated product could make it through to the buyer-facing catalog again.
The delivery decisions
Repair the operating path, including the exceptions.
Verify the result where the buyer sees it
The recovery connected server investigation to catalog behavior. Restoring a background process was a necessary step; confirming that changed product data reached the search index established what the repair meant for operations. This kept the work focused on the full route from a merchandise update to a discoverable item.
Let receiving continue when the preferred bins are full
Warehouse allocation needed a specific fallback: use a small bin first, use an extra-small bin when that preferred capacity is exhausted, and return to the original preference when small bins become available. Shinetech implemented that sequence in the existing workflow. The recovery condition matters as much as the fallback; otherwise a temporary shortage can turn into a permanent allocation habit.
Make larger exports practical
Operational reports had another constraint: assembling a large CSV in memory could make exporting unreliable. The team changed the export to write data progressively and refined inventory-report presentation and sorting. Staff could retrieve the operating data through the established reporting workflow without the application having to retain the entire export at once.
How the workflow holds together
The platform could not be treated as an isolated website.
Working across dependencies
A deployment change could affect the storefront, administration, background tasks, and related sites together. Infrastructure work therefore included configuration compatibility, checks in separate environments, gradual switching, and a rollback path. The objective was to improve the system with an understanding of the dependencies that were already carrying orders and warehouse work.
This engagement combined fault investigation with smaller business-rule changes. Those activities addressed the same practical concern: whether the next person in the process could complete their task. A saved category change had to become visible; a received item needed an available location; an operations report needed to finish exporting.
The delivered result
Catalog visibility, receiving, and reporting had working paths again.
Receiving continuity
Explicit bin priorities handle shortages and return to the preferred type when capacity is available.
Progressive exports
Large CSV output is written in stages, reducing the need to hold all rows in memory.
Development and maintenance continue on the existing platform. The case documents operational repairs and capabilities, without attributing sales growth or a zero-downtime outcome to them.
Case taxonomy
Searchable by industry, technology, product, and business need.
Industry and product
- E-commerce & Retail
- Wholesale operations
- B2B commerce
Technology and delivery
- Web commerce
- Search indexing
- Data services
- Legacy modernization
Business need
- Product search
- Warehouse rules
- Operational recovery
- Inventory receiving
- Reporting
Discuss your project
Are small platform failures disrupting daily operations?
Tell us how your business works and where your software needs to change.
Get in touch
Ready to build software that fits your business?
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review