VouDeOfertas

Plateforme de suivi de prix multi-marketplace (Amazon, Mercado Livre, Shopee) qui expose l'historique réel des prix pour distinguer une vraie promotion d'une remise artificielle.

Couverture de la page d'accueil de VouDeOfertas montrant une carte d'historique de prix sur 90 jours d'un produit et des indicateurs de confiance de l'offre.

Problème

Des marketplaces comme Amazon, Mercado Livre et Shopee publient des promotions sans historique fiable. Le défi produit était d'exposer l'historique réel des prix pour distinguer offre réelle et remise artificielle — et, côté ingénierie, d'unifier le scraping de sources hétérogènes sans corrompre le catalogue lors des retries.

Solution et impact

Système full-stack en monorepo Turborepo avec ingestion par lots, hash de contenu et files BullMQ pour garder le pipeline idempotent. La collecte est HTTP-first (Undici + Cheerio), avec Playwright seulement quand la page bloque ou exige un rendu. Persistance MySQL avec cache Redis et frontend Next.js/React pour l'historique analytique. L'impact d'ingénierie est un flux résilient aux blocages et retries — sans KPIs business inventés.

Architecture et compromis

Compromis central : privilégier HTTP léger et bon marché, réserver Playwright aux exceptions — plus de débit, moins de coût browser, au prix de deux chemins de collecte. Batch + hash évite de dupliquer produit ou prix en cas de retry. Redis couvre les lectures chaudes de l’historique ; MySQL reste la source de vérité. Le monorepo simplifie les contrats entre scraper, API et UI, au coût d’une discipline de boundaries Turborepo.

Diagrama de fluxo de dados do VouDeOfertas: marketplaces, scraper, BullMQ, MySQL/Redis, API e Next.js

Exploitation et observabilité

Docker e GitHub Actions para deploy reproduzível; healthchecks nos serviços. Telemetria por conector ainda é lacuna consciente — retrospectiva aponta métricas de bloqueio e drift de seletor como próximo investimento.

Défis techniques

Hétérogénéité des marketplaces (markup, anti-bot, SPA), retries qui ne doivent pas dupliquer d'entités, et garder le pipeline opérable avec Docker et GitHub Actions sans sur-ingénierie d'observabilité à ce stade.

Ce que je ferais autrement

Aujourd'hui j'extrairais des adapters par marketplace avec des contrats de parsing plus explicites, et j'investirais plus tôt dans des métriques d'échec par source (taux de blocage, drift de sélecteur). Le design HTTP-first + fallback reste juste ; ce que j'avancerais, c'est la télémétrie par connecteur pour réagir plus vite quand un site change.

Contexte technique

  • Multi-marketplaceSourcesPipeline unifié et collecte hétérogène
  • HTTP-firstCollectePlaywright seulement en exception

Décisions documentées (ADR)

Stack

  • Next.js
  • React
  • TypeScript
  • Node.js
  • Express
  • MySQL
  • Redis
  • BullMQ
  • Undici
  • Cheerio
  • Playwright
  • Docker
  • GitHub Actions