VouDeOfertas

Plataforma de monitoramento de preços multi-marketplace (Amazon, Mercado Livre, Shopee) que expõe histórico real de preço para separar promoção genuína de desconto artificial.

Capa da home do VouDeOfertas mostrando card de histórico de preço de 90 dias de um produto e indicadores de confiança de oferta.

Problema

Marketplaces como Amazon, Mercado Livre e Shopee publicam promoções sem contexto histórico confiável. O desafio de produto era expor o histórico real de preço para separar promoção genuína de desconto artificial — e, no lado de engenharia, unificar scraping de fontes heterogêneas sem corromper o catálogo quando retries falham.

Solução e impacto

Sistema full-stack em monorepo Turborepo com ingestão em batch, hash de conteúdo e filas BullMQ para tornar o pipeline idempotente. A coleta é HTTP-first (Undici + Cheerio), com fallback Playwright só quando a página bloqueia ou exige renderização. Persistência em MySQL com cache Redis e frontend Next.js/React com histórico analítico. O impacto de engenharia é um fluxo resiliente a bloqueios e retries — sem métricas de conversão de negócio inventadas.

Arquitetura e trade-offs

Trade-off central: priorizar HTTP leve e barato, reservando Playwright para exceções — mais throughput e menos custo de browser, ao preço de manter dois caminhos de coleta. Batch + hash evita duplicar produto ou preço em falhas de retry. Redis cobre leituras quentes do histórico; MySQL permanece a fonte de verdade. O monorepo simplifica contratos entre scraper, API e UI, com o custo de disciplina de boundaries no Turborepo.

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

Operação e observabilidade

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.

Desafios técnicos

Heterogeneidade dos marketplaces (markup, anti-bot, SPA), retries que não podem duplicar entidades, e manter o pipeline operável com Docker e GitHub Actions sem over-engineering de observabilidade no estágio atual.

O que eu faria diferente

Hoje eu extrairia adapters por marketplace com contratos de parsing mais explícitos e investiria antes em métricas de falha por fonte (taxa de bloqueio, drift de seletor). O desenho HTTP-first + fallback continua certo; o que eu adiantaria é telemetria por conector para reduzir o tempo de reação quando um site muda.

Contexto técnico

  • Multi-marketplaceFontesPipeline unificado com coleta heterogênea
  • HTTP-firstColetaPlaywright só em exceções

Decisões documentadas (ADR)

Stack

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