Nie podano
47 ofert
Istnieje działająca platforma produkcyjna z katalogiem i automatycznym aktualizowaniem zewnętrznych ofert i cen.
Stos technologiczny:
— Node.js / TypeScript;
— PostgreSQL;
— istniejąca usługa odświeżania cen i cron;
— oddzielny gotowy moduł walidacji i wyboru ofert w Pythonie;
— staging i produkcja.
Konieczne jest punktowe dopracowanie istniejącego pipeline'u odświeżania cen bez pełnego przepisywania backendu.
OBOWIĄZKOWY ZAKRES
1. Integracja modułu Python
— Moduł Python pozostaje oddzielnym komponentem;
— zwraca zorganizowany wynik: oferty, wybrana oferta, statusy i flagi ryzyka;
— Node.js waliduje wynik i wykonuje zapis w bazie danych;
— przewidzieć obsługę błędów i częściowych/nieudanych uruchomień;
— pipeline dziedziczony nie jest wyłączany do zakończenia QA.
2. Uruchomienie odświeżania według listy
Dodaj uruchomienie:
— po jednym slug/id;
— po przekazanej liście slug/id.
Możliwe CLI lub istniejące API serwisowe. Nowy interfejs użytkownika nie jest wymagany.
3. Tryb Shadow
Nowe wyniki powinny być zapisywane oddzielnie i nie wpływać na produkcję do QA.
Wymagane pola shadow:
— cena;
— ID wybranej oferty;
— bezpośredni URL;
— status oferty;
— flagi ryzyka/QA;
— checkedAt;
— engineVersion.
4. Rozszerzenie istniejącej tabeli ofert
Dodaj:
— źródło;
— external_offer_id;
— last_seen_at;
— last_checked_at;
— engine_version;
— flagi ryzyka lub przechowywanie w istniejącym JSON;
— unikalne ograniczenie dla ochrony przed duplikatami.
Nie jest wymagane tworzenie nowego równoległego systemu ofert, jeśli istniejącą tabelę można bezpiecznie rozszerzyć.
5. UPSERT, STALE i transakcja DB
Zamień obecną schemę DELETE → CREATE:
— UPSERT istniejących i nowych ofert;
— oferty, które nie występują w pełnym udanym snapshot, są przekazywane do STALE;
— w przypadku błędu API, częściowego wyniku lub niedokończonego snapshot aktywne oferty nie powinny stawać się STALE;
— aktualizacja ofert, metadanych wybranej oferty i pól shadow według jednego modelu odbywa się w ramach jednej transakcji DB;
— w przypadku błędu wykonywany jest pełny rollback.
6. Bezpieczne odświeżanie kanoniczne
Odświeżanie cen nie powinno zmieniać:
— marki;
— referencji;
— modelu;
— kolekcji;
— nazwy/tytułu;
— slug;
— opisów;
— obrazów;
— pól SEO.
Aktualizowane są tylko oferta, cena i dane shadow.
7. Zachowanie obecnej logiki cron
Zachować:
— istniejący cron;
— rolling batches;
— cooldown;
— sprawdzenie PRICE_REFRESH_MIN_DAYS przed wywołaniem zewnętrznego API;
— dziedziczony pipeline produkcyjny do zakończenia Shadow QA.
8. Audyt wyników
Wystarczy jedna opcja:
— kolumna shadow w istniejącej tabeli administracyjnej;
lub
— eksport CSV.
Minimalne dane:
— model/referencja;
— cena produkcyjna;
— cena shadow;
— delta;
— URL produkcyjny/shadow;
— status;
— flagi ryzyka;
— checkedAt;
— engineVersion.
Nowy skomplikowany dashboard nie jest wymagany.
9. Staging i QA
— migracje DB;
— wdrożenie staging;
— test dymny na 5 przekazanych modelach;
— następnie Tryb Shadow na około 50 modelach;
— naprawa błędów technicznych wykrytych podczas tych uruchomień;
— krótka dokumentacja kontraktu Python → Node.js i procedura rollback.
OPCJONALNIE OCENIĆ ODDZIELNIE
Prosta promocja techniczna bez nowego UI:
— promocja jednego modelu po slug;
— promocja listy slug;
— przeniesienie potwierdzonych wartości shadow do produkcji;
— techniczna weryfikacja po rollout.
WYNIK
— Pull Request;
— migracje DB;
— działająca integracja Python → Node.js;
— Tryb Shadow;
— UPSERT, STALE i transakcyjne aktualizacje;
— uruchomienie po slug/id;
— wdrożenie staging;
— wyniki testu dymnego;
— krótka dokumentacja;
— nie mniej niż 7 dni na poprawki błędów w zrealizowanym zakresie po akceptacji.
W ODPOWIEDZI WSKAZAĆ
1. Stała cena za obowiązkowy zakres.
2. Oddzielny koszt mechanizmu promocji.
3. Termin.
4. Ocena godzin.
5. Kiedy gotowi do rozpoczęcia.
6. Doświadczenie z transakcjami PostgreSQL, migracjami i pipeline'ami wczytywania.
7. Jakie pytania należy wyjaśnić przed rozpoczęciem.
8. Czy wliczone są staging, QA, migracje i okres naprawy błędów.
Szablonowe odpowiedzi bez konkretnej oceny nie będą rozpatrywane.
Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca zaczyna się od ograniczonego przeglądu kodu i stagingu.
