A UK retailer was maintaining the same catalogue by hand in two storefronts. This is what replaced that, and what it cost them not to have it sooner.
UK e-commerce retailer
via Maxenius Solutions
2024 to 2025
Backend engineer, team lead
Laravel, then Python
MySQL · AWS · Queue workers
Shopify · eBay
REST and webhooks
The client sold the same catalogue through a Shopify storefront and an eBay shop. Both were maintained by hand. When a price changed, someone edited it twice. When stock moved, someone remembered to update the other channel, or did not.
The cost of forgetting was not theoretical. Overselling on eBay meant cancelling orders, which meant refunds, seller rating damage and support time. The team’s answer had been to keep a buffer of unsold stock on eBay, which quietly capped how much they could sell.
One person spent roughly a full working day each week on reconciliation. The brief I was given was narrow: make the two catalogues agree, and stop the overselling. I later led the small team that built and extended it.
The naive version of this, a script that loops every product and pushes it, fails on all four of these.
Both APIs cap calls per second. A full catalogue pass at 300k items is days of API budget, not minutes.
Shopify variants and eBay listings do not map one to one. Categories, attributes and shipping profiles all needed translation.
A sync that dies halfway must not leave the two systems in a worse state than it found them.
The shop kept trading throughout. Nothing could be rebuilt from scratch behind a maintenance page.
| Measure | Before | After |
|---|---|---|
| Catalogue update path | Edited by hand in both systems | Edited once in Shopify, propagated automatically |
| Time to propagate | Hours to days, if remembered | Under a minute |
| Weekly reconciliation | About 20 hours of one person | A short exception list, minutes |
| Overselling | Recurring, absorbed by a stock buffer | Buffer no longer needed |
| Failure visibility | Noticed when a customer complained | Dead letter queue, reviewed daily |
| Listings covered | Whatever fit in the week | 300,000+, continuously |
Build the exception dashboard first. For the first few weeks the dead letter queue was inspected through database queries, which meant only I could triage it. A simple screen would have handed that to the ops team a month earlier.
Instrument sooner. Metrics on queue depth and sync lag were added after the first incident rather than before it. They should have shipped with the first write enabled category. They are cheap up front and expensive to retrofit under pressure.
Push harder on the attribute mapping. A chunk of early dead letter volume came from category attributes that were guessable but not agreed. A day with the client’s product lead at the start would have removed weeks of noise.
Twenty minutes is usually enough for me to tell you whether the fix is a week or a quarter, and whether it is worth doing at all.