Article

Why Ecommerce Product-Import Pipelines Fail

The failure modes I see repeatedly in supplier feed and product-import systems — and how to design around them.

They rarely fail loudly

The import pipelines that cause real damage don't crash — they succeed partially and quietly. A feed truncated at 80% still "runs successfully." A currency field silently defaulting to the wrong unit still "imports." The failure modes worth designing around are the ones that don't throw an exception.

Common failure patterns

Silent partial failures. A job that processes 8,000 of 10,000 rows and reports success on the 8,000 is often worse than a job that fails outright — it looks healthy in every dashboard while quietly corrupting the catalogue.

Unowned unit and category mapping. Every supplier has its own idea of units and categories. Without an explicit, versioned mapping layer — not a pile of if-statements — these mismatches compound for months before anyone notices the pattern.

No rollback path. Eventually a bad import gets published. If there's no way to revert to the last known-good state quickly, that one bad run becomes a multi-day cleanup project instead of a five-minute fix.

Testing that doesn't reflect real chaos. Import pipelines tested against clean, hand-crafted sample files pass every test and still break on day one against a real supplier's actual export — because real feeds are inconsistent in ways nobody thinks to fabricate in a test fixture.

Where pipelines actually break

Feed arrives

Truncated, reordered, re-encoded

Parsed 'successfully'

Partial data, no error thrown

Published

Looks healthy in every dashboard

Discovered

Days later, by a customer or a stockout

What actually holds up

Validate at every boundary, diff before publishing, own unit/category mapping explicitly and version it, and keep a fast rollback path for when — not if — something bad gets published anyway. I go into how this plays out in practice in the catalogue automation and Shopify/Amazon sync case studies.