Catalogue indexing under load
Indexer strategy and scheduling so a price or stock update does not lock the catalogue while customers are on it.
A Magento backend that had to hold on campaign day.
Frankenspalter (frankenspalter.ch) is a Swiss retail operation running thousands of orders a day. The work was the layer underneath the storefront: catalogue indexing, caching, order processing and an ERP integration that has to keep running while the store keeps selling.
- Market
- Switzerland · Retail e-commerce
- Stack
- Magento · ERP · Caching · Queues
- Languages
- Türkçe · English · العربية
- Response
- A straight answer on fit within a day
What was built.
The order path from ERP through the Magento core to the catalogue, checkout and order queue — with each stage able to absorb a spike without passing it on.
Caching that survives invalidation
Full-page and block caching arranged so an ERP sync does not flush everything at the moment traffic peaks.
Order processing as a queue
Order handling moved off the request path, so a slow downstream system delays fulfilment rather than checkout.
ERP integration
Products, prices, stock and orders moving both ways, with an explicit source of truth per field and retries that cannot duplicate a document.
Infrastructure and release workflow
Deployment, cron and queue-consumer health made visible, so a stalled consumer is an alert rather than a discovery.
The situation.
A platform that worked on an ordinary Tuesday and became a liability on the days that mattered commercially.
Traffic peaks are commercial events
The days the platform was least stable were the days the business earned the most.
The ERP and the storefront wanted the same resources
Sync jobs and customer requests competed for the database at exactly the wrong moments.
A large catalogue that changes constantly
Price and stock updates arriving all day meant indexing was never finished.
Failures were found by customers
There was no signal when a queue consumer died — only the orders that did not arrive.
Related systems.
Dcey · dcey.com.tr
The same commerce platform taken headless, with rental rules in the commerce layer.
Read the case study →Edip Saat · edipsaat.com
Store, ERP, warehouse and accounting reporting one stock figure.
Commerce ↔ ERP ↔ WMS
Questions people ask.
What changed most?
The failure mode. Before, a spike in traffic or a heavy sync could take the storefront with it. After, the same events queue and drain — fulfilment might run a few minutes behind, but the store keeps taking orders.
Is this work repeatable on another Magento store?
The method is: measure the real traffic, find which stage blocks, move that stage off the request path, then make its health visible. The specific fixes differ per store, which is why the work starts with an audit rather than a proposal.
Have a complex system to build or scale?
Tell me what you are trying to build, automate or scale. You get a straight answer on fit within a day — and a name to call if it is not me.
- [email protected]
- linkedin.com/in/zakaria-haj-mohamad-87188b11b