Why platform integrations fall apart in the field (and how we fixed ours)
Getir, Trendyol and Yemeksepeti each behave differently with catalogues. We rewrote our sync engine from scratch; here is what we learned about distributed matching.
Everything works in the integration demo. The trouble starts in month three: a product is deleted on the platform but lingers on your side; an old price fails to return when a promotion ends; a branch goes on holiday and still takes orders on three of four platforms.
Root cause: matching by name instead of identity
Our first architecture matched products by name similarity. That worked at 85% accuracy — and a 15% error rate across thousands of daily orders is unacceptable. At the centre of the rewrite was keeping a persistent external-ID map per platform.
Three platforms, three models of reality
- One platform accepts partial updates; another wants the full catalogue every time.
- Marking something out of stock works at product level in one place and at variant level in another.
- A promotional price is a separate field on one platform and overwrites the base price on another.
- Error codes are not standardised; the same condition can return three different messages.
Queues, retries and idempotency
We stopped doing sync as a direct HTTP call. Every change now enters a queue as an event, the handler is idempotent, and failed work retries with exponential backoff. Processing the same event twice does not corrupt anything — non-negotiable in a distributed system.
None of it works without observability
The biggest win wasn't the engine itself; it was being able to answer "what state is this product in, on which platform, right now" from a single screen. Support resolution time halved once that screen shipped.
In a distributed system the real feature isn't synchronisation — it's being able to tell when synchronisation has broken.
