The latest articles on DEV Community by Jonathan Ruimi (@jonathanruimi_vinyasa). https://dev.to/jonathanruimi_vinyasa https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4016640%2Fde87c2b4-2684-4552-bfbc-3e0086f09ccc.png https://dev.to/jonathanruimi_vinyasa en Jonathan Ruimi Sun, 05 Jul 2026 19:55:14 +0000 https://dev.to/jonathanruimi_vinyasa/building-an-auto-parts-dropshipping-catalog-lessons-from-180k-skus-4a7 https://dev.to/jonathanruimi_vinyasa/building-an-auto-parts-dropshipping-catalog-lessons-from-180k-skus-4a7 <p>Aggregating auto-parts catalogs from several distributors sounds like a plumbing problem until you actually try it. Once you are ingesting feeds from four different suppliers, each with its own format, encoding, and idea of what a "product" is, the hard part stops being the download and becomes reconciliation. Here are the lessons that stuck after building a catalog that now spans more than 180,000 SKUs.</p> <h2> Every supplier speaks a different dialect </h2> <p>One supplier ships a 1.4M-row comma-separated file over SFTP with space-padded columns. Another gives you a UTF-8-BOM CSV plus a separate stock-only file that refreshes more often. A third has no feed at all and has to be scraped. A fourth hands you a Latin-1 snapshot with tri-state stock (Yes / Low / No) and no barcodes anywhere.</p> <p>The practical takeaway: normalize aggressively at the edge and keep the raw parse dumb. We stream each feed straight into an UNLOGGED staging table with <code>COPY</code>, then do a single set-based upsert. Trying to be clever in the row parser (or pushing parsing into SQL) was consistently slower than a plain streaming parser feeding a bulk load, because the workload is I/O-bound, not CPU-bound.</p> <h2> Matching products across suppliers is the whole game </h2> <p>The moment two suppliers sell the same part, you want to show cost, margin, and stock side by side. That requires deciding they <em>are</em> the same part. GTIN/UPC is the strongest signal, but barcodes are messy: some are junk (too short), some suppliers omit them entirely, and manufacturer part numbers collide across brands.</p> <p>We settled on honest, explicit match tiers instead of one fuzzy score:</p> <ul> <li> <strong>exact</strong> — both suppliers carry a valid GTIN-14 and they agree.</li> <li> <strong>verified</strong> — a GTIN backfilled from an authoritative echo (a product page UPC).</li> <li> <strong>probable</strong> — manufacturer part number plus brand agreement, no barcode.</li> <li> <strong>none</strong> — single supplier, no cross-match.</li> </ul> <p>Normalization (stripping, casing, check-digit handling) is the actual contract here, so it lives in exactly one place and is unit-tested. A backfilled or MPN-based link never gets to masquerade as a hard dual-barcode match. Keeping the confidence label honest is what keeps buyers from seeing two unrelated parts merged into one listing.</p> <h2> Dropship fulfilment needs a fast stock path </h2> <p>Listing a part you cannot ship is worse than not listing it. A daily full feed is fine for pricing but too stale for inventory, so the stock-only refresh runs on a much tighter cadence and a 5-minute oversell guard pushes quantity zero to every sales channel the instant a supplier goes out of stock.</p> <p>If you are curious what this looks like as a live storefront, it powers <a href="https://vinyasa-automotive.com" rel="noopener noreferrer">Vinyasa Automotive</a>. The engineering lesson generalizes to any multi-source catalog: keep parsing dumb, make matching explicit and testable, and treat inventory freshness as a first-class latency problem.</p> ecommerce webdev database python