Not specified
45 proposals
There is an active production platform with a catalog and automatic updates of external offers and prices.
Stack:
— Node.js / TypeScript;
— PostgreSQL;
— existing price refresh service and cron;
— separate ready Python module for validation and selection of offers;
— staging and production.
It is necessary to make targeted improvements to the existing price refresh pipeline without completely rewriting the backend.
MANDATORY SCOPE
1. Integration of the Python module
— The Python module remains a separate component;
— returns a structured result: offers, selected offer, statuses, and risk flags;
— Node.js validates the result and performs a write to the database;
— provide for error handling and partial/failed runs;
— the legacy pipeline is not turned off until QA is completed.
2. Launch refresh by list
Add launch:
— by one slug/id;
— by the provided list of slug/id.
Assume CLI or existing service API. A new user interface is not required.
3. Shadow Mode
New results must be recorded separately and not affect production until QA.
Shadow fields required:
— price;
— selected offer ID;
— direct URL;
— offer status;
— risk/QA flags;
— checkedAt;
— engineVersion.
4. Expanding the existing offers table
Add:
— source;
— external_offer_id;
— last_seen_at;
— last_checked_at;
— engine_version;
— risk flags or storage in existing JSON;
— unique constraint to protect against duplicates.
It is not required to create a new parallel offer system if the existing table can be safely expanded.
5. UPSERT, STALE, and DB transaction
Replace the current DELETE → CREATE scheme:
— UPSERT existing and new offers;
— offers missing in the full successful snapshot are translated to STALE;
— in case of API error, partial result, or incomplete snapshot, active offers should not become STALE;
— updating offers, selected offer metadata, and shadow fields for one model is performed within one DB transaction;
— in case of an error, a full rollback is performed.
6. Canonical-safe refresh
Price refresh should not change:
— brand;
— reference;
— model;
— collection;
— name/title;
— slug;
— descriptions;
— images;
— SEO fields.
Only offer, price, and shadow data are updated.
7. Preserving current cron logic
Preserve:
— existing cron;
— rolling batches;
— cooldown;
— checking PRICE_REFRESH_MIN_DAYS before calling the external API;
— legacy production pipeline until Shadow QA is completed.
8. Audit output
One option is sufficient:
— shadow columns in the existing admin table;
or
— CSV export.
Minimum data:
— model/reference;
— production price;
— shadow price;
— delta;
— production/shadow URL;
— status;
— risk flags;
— checkedAt;
— engineVersion.
A new complex dashboard is not required.
9. Staging and QA
— DB migrations;
— staging deployment;
— smoke test on 5 provided models;
— then Shadow Mode on approximately 50 models;
— fixing technical errors identified during these runs;
— brief documentation of the Python → Node.js contract and rollback procedure.
OPTIONALLY ASSESS SEPARATELY
Simple technical promotion without a new UI:
— promotion of one model by slug;
— promotion of a list of slugs;
— transferring confirmed shadow values to production;
— technical check after rollout.
RESULT
— Pull Request;
— DB migrations;
— working integration Python → Node.js;
— Shadow Mode;
— UPSERT, STALE, and transactional update;
— launch by slug/id;
— staging deployment;
— smoke-test results;
— brief documentation;
— at least 7 days of bug fixes for the implemented scope after acceptance.
IN RESPONSE, INDICATE
1. Fixed price for the mandatory scope.
2. Separate cost for the promotion mechanism.
3. Timeline.
4. Hourly estimate.
5. When you are ready to start.
6. Experience with PostgreSQL transactions, migrations, and ingestion pipelines.
7. What questions need to be clarified before starting.
8. Whether staging, QA, migrations, and bug-fix period are included.
Template responses without specific estimates will not be considered.
Access to production is not provided at the first stage. Work begins with limited code review and staging.
