Більшість людей, які відкривають магазин дропшипінгу, шукають коротких шляхів. Вони гортають форуми в пошуках виграшних товарів, наймають дешевих віртуальних асистентів і сподіваються, що алгоритм принесе багатство за одну ніч. Мене це ніколи не приваблювало. Я розглядав дропшипінг як інженерну задачу. Я не гнався за швидкими грошима. Я хотів вирішити проблему синхронізації запасів, побудувати алгоритми ціноутворення, що реагують на реальні зміни ринку, і боротися з API постачальників, не втрачаючи при цьому розуму. Магазин став побічним продуктом системи, яку я побудував за допомогою Node.js та PostgreSQL.

Ставтеся до магазину як до бекенд-сервісу

Тієї миті, коли ви перестаєте сприймати дропшипінг як маркетингову гонитву і починаєте ставитися до нього як до виклику в архітектурі розподілених систем, проблеми стають цікавими. Як підтримувати актуальність вітрини, коли три різні постачальники контролюють ваші запаси? Як встановлювати конкурентоспроможні ціни, коли ті самі постачальники змінюють вартість, не повідомляючи вас? Як керувати каталогом, що розростається з п'ятдесяти SKU до п'яти тисяч, не потопаючи в електронних таблицях?

Я побудував конвеєр (pipeline), щоб відповісти на ці запитання. Node.js забезпечував подієво-орієнтовану архітектуру, оскільки мені потрібен був неблокуючий ввід-вивід (non-blocking I/O) для одночасного керування кількома з'єднаннями з постачальниками. PostgreSQL слугував надійним джерелом істини (source of truth). Я приділяв велику увагу дизайну схеми, тому що неохайна таблиця запасів перетворюється на кошмар, щойно ви вперше продасте товар, якого не існує.

Побудова конвеєра

Основне завдання було простим: отримувати дані про товари з API постачальників. На практиці це означало збір SKU, описів, зображень, рівнів запасів і цін з ендпоінтів, які ніколи не були розроблені для взаємодії між собою. Я написав сервіси опитування (polling services) на Node.js, які зверталися до фідів постачальників з нерівномірними інтервалами. Кожен вхідний пакет даних проходив через шари валідації та мапінгу, перш ніж потрапити в нашу внутрішню базу даних магазину.

Я структурував PostgreSQL за допомогою окремих таблиць для товарів, варіантів, історії цін і логів синхронізації. Коли постачальник непомітно змінював назву поля або надсилав null там, де раніше було число, конвеєр перехоплював це і записував запис про помилку замість того, щоб пошкодити дані вітрини. Я міг подивитися на рядок у логах і точно знати, який саме ендпоінт зламався, коли це сталося і які поля були некоректними. Ця можливість спостереження (observability) рятувала мене не раз, коли постачальник вирішував «оновити» свій API протягом вихідних.

Що спрацювало добре

Автоматизація заощадила величезну кількість часу. На початку я пробував ручний підхід: завантажував таблиці постачальників, очищував їх вручну, форматував зображення та завантажував CSV-файли в магазин. Це стало неможливим, щойно каталог перевищив кілька десятків позицій. Автоматизований конвеєр обробляв нові позиції, оновлення цін і коригування запасів без моєї участі в роботі з таблицями.

Масштабування описів товарів відбувалося за допомогою шаблонів. Писати унікальні тексти для п'ятисот майже ідентичних товарів неможливо в довгостроковій перспективі. Замість цього я створив шар шаблонізації, який брав атрибути постачальника, такі як матеріал, розміри або колір, і вставляв їх у структуровані блоки описів. Результат був достатньо чистим для конверсії та достатньо послідовним, щоб додавання тисячі нових SKU не потребувало ручного копірайтингу.

Моніторинг цін також перевершив мої очікування. Я створив легкий шар моніторингу, який відстежував ціни конкурентів на підмножині ключових товарів. Коли система виявляла зміни, вона автоматично коригувала нашу маржу в межах налаштованих мною обмежень (guardrails). Якщо постачальник знижував оптову ціну, ціна в оголошенні могла відобразити цю зміну протягом хвилин, а не днів. Така швидкість реагування суттєво вплинула на товари з низькою маржею.

Що зламалося і чому

API постачальників не мають стабільності. Це не скарга, це геологічний факт. Один партнер надає чистий JSON із передбачуваною пагінацією. Інший повертає XML із тегами у camelCase у понеділок і snake_case у середу. Ліміти запитів (rate limits) варіюються від щедрих до каральних. Про простої повідомляється через HTML-сторінки помилок, а не через належні статус-коди. У підсумку ви пишете захисні парсери та логіку повторних спроб (retry logic) для ендпоінтів, які поводяться так, ніби їх розробляли у 2003 році.

Синхронізація залишків мала стан гонитви (race conditions), через що я втрачав сон. Уявіть собі: двоє клієнтів замовляють останню одиницю товару з інтервалом у кілька секунд, або вебхук постачальника повідомляє, що залишки обнулилися саме в той момент, коли покупець натискає «оформити замовлення». Моя початкова логіка «спочатку прочитай, потім онови» (read-then-update) зазнала катастрофічного провалу. Мені довелося переписати шар синхронізації, використовуючи атомарні транзакції PostgreSQL та песимістичне блокування (pessimistic locking) для високооборотних SKU. Це був болючий практичний урок із паралелізму (concurrency), до якого жоден туторіал не підготує так, як ситуація, коли на кону стоять реальні гроші.

Моєю найбільшою помилкою було ігнорування автоматизації підтримки клієнтів. Я був одержимий конвеєрами даних (data pipelines) і сприймав наслідки для людей як щось другорядне. Замовлення приходили із запізненням. Постачальники відправляли не той колір. Клієнти надсилали електронні листи, які годинами лежали в моїй пошті, поки я налагоджував таймаути API. У мене не було маршрутизації тікетів, автоматичних відповідей чи передачі запитів чат-боту. Технічна інфраструктура була надійною. Людської інфраструктури бракувало, і цей розрив зашкодив бізнесу більше, ніж будь-який нестабільний вебхук.

Тестування зображень як інженер

Я провів побічний експеримент із зображеннями товарів. Я показував різним користувачам різні головні (hero) зображення, використовуючи простий маршрутинг через параметри URL, прив'язаний до сегментації на основі сесій (session-based bucketing). Один варіант показував товар на чистому білому фоні. Інший — у лайфстайл-середовищі, на справжньому робочому столі. Я відстежував рівень конверсії для кожного сегмента за допомогою базового логування подій, безпосередньо пов'язаного з процесом оформлення замовлення.

Невеликі зміни покращили рівень залученості. Лайфстайл-знімки не завжди перемагали, але коли це траплялося, приріст був достатньо значним, щоб змінити те, як я розставляв пріоритети