# 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.

- **Email:** hello@zhajmohamad.com
- **URL:** https://zhajmohamad.com/projects/frankenspalter

## 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.

- **Catalogue indexing under load** — Indexer strategy and scheduling so a price or stock update does not lock the catalogue while customers are on it.
- **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.
- **Edip Saat (edipsaat.com)** — Store, ERP, warehouse and accounting reporting one stock figure.

## 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.

## Related specialisms.

- [Magento / Adobe Commerce architect](https://zhajmohamad.com/magento-adobe-commerce)
- [Magento ERP & payment integrations](https://zhajmohamad.com/magento-integrations)
- [Custom e-commerce development](https://zhajmohamad.com/ecommerce)
- [Custom API & system integration](https://zhajmohamad.com/system-integration)

---

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.