Не указан
47 ставок
Есть действующая production-платформа с каталогом и автоматическим обновлением внешних предложений и цен.
Стек:
— Node.js / TypeScript;
— PostgreSQL;
— существующий price refresh service и cron;
— отдельный готовый Python-модуль валидации и выбора предложений;
— staging и production.
Необходимо точечно доработать существующий price refresh pipeline без полного переписывания backend.
ОБЯЗАТЕЛЬНЫЙ SCOPE
1. Интеграция Python-модуля
— Python-модуль остаётся отдельным компонентом;
— возвращает структурированный результат: offers, selected offer, statuses и risk flags;
— Node.js валидирует результат и выполняет запись в БД;
— предусмотреть обработку ошибок и partial/failed runs;
— legacy pipeline не отключается до завершения QA.
2. Запуск refresh по списку
Добавить запуск:
— по одному slug/id;
— по переданному списку slug/id.
Допустим CLI или существующий служебный API. Новый пользовательский интерфейс не требуется.
3. Shadow Mode
Новые результаты должны записываться отдельно и не влиять на production до QA.
Требуются shadow-поля:
— price;
— selected offer ID;
— direct URL;
— offer status;
— risk/QA flags;
— checkedAt;
— engineVersion.
4. Расширение существующей таблицы offers
Добавить:
— source;
— external_offer_id;
— last_seen_at;
— last_checked_at;
— engine_version;
— risk flags либо хранение в существующем JSON;
— unique constraint для защиты от дублей.
Новую параллельную offer-систему создавать не требуется, если существующую таблицу можно безопасно расширить.
5. UPSERT, STALE и DB transaction
Заменить текущую схему DELETE → CREATE:
— UPSERT существующих и новых offers;
— отсутствующие в полном успешном snapshot offers переводятся в STALE;
— при API error, partial result или незавершённом snapshot активные offers не должны становиться STALE;
— обновление offers, selected offer metadata и shadow fields по одной модели выполняется внутри одной DB transaction;
— при ошибке выполняется полный rollback.
6. Canonical-safe refresh
Price refresh не должен изменять:
— brand;
— reference;
— model;
— collection;
— name/title;
— slug;
— descriptions;
— images;
— SEO fields.
Обновляются только offer, price и shadow data.
7. Сохранение текущей cron-логики
Сохранить:
— existing cron;
— rolling batches;
— cooldown;
— проверку PRICE_REFRESH_MIN_DAYS до вызова внешнего API;
— legacy production pipeline до завершения Shadow QA.
8. Audit output
Достаточно одного варианта:
— shadow-колонки в существующей admin table;
или
— CSV export.
Минимальные данные:
— model/reference;
— production price;
— shadow price;
— delta;
— production/shadow URL;
— status;
— risk flags;
— checkedAt;
— engineVersion.
Новый сложный dashboard не требуется.
9. Staging и QA
— DB migrations;
— staging deployment;
— smoke test на 5 переданных моделях;
— затем Shadow Mode приблизительно на 50 моделях;
— исправление технических ошибок, выявленных во время этих прогонов;
— краткая документация контракта Python → Node.js и rollback procedure.
ОПЦИОНАЛЬНО ОЦЕНИТЬ ОТДЕЛЬНО
Простой технический promotion без нового UI:
— promotion одной модели по slug;
— promotion списка slug;
— перенос подтверждённых shadow values в production;
— техническая проверка после rollout.
РЕЗУЛЬТАТ
— Pull Request;
— DB migrations;
— рабочая интеграция Python → Node.js;
— Shadow Mode;
— UPSERT, STALE и транзакционное обновление;
— запуск по slug/id;
— staging deployment;
— smoke-test results;
— краткая документация;
— не менее 7 дней исправления багов по реализованному scope после приёмки.
В ОТКЛИКЕ УКАЗАТЬ
1. Fixed price за обязательный scope.
2. Отдельную стоимость promotion-механизма.
3. Срок.
4. Оценку часов.
5. Когда готовы начать.
6. Опыт с PostgreSQL transactions, migrations и ingestion pipelines.
7. Какие вопросы нужно уточнить до начала.
8. Включены ли staging, QA, migrations и bug-fix period.
Шаблонные ответы без конкретной оценки рассматриваться не будут.
Доступ к production на первом этапе не предоставляется. Работа начинается с ограниченного code review и staging.
