DeBuget — comparator de prețuri cu 750.000 de produse și feed-uri zilnice din 70+ magazine

Contextul de business

Modelul comparatorului de prețuri (compari.ro, price.ro) există în România din 2000, dar majoritatea platformelor au infrastructură veche: pagini lente (LCP 3-5s), căutare greoaie, date stocate o săptămână. DeBuget trebuia să rezolve trei probleme: (1) ingest a 70+ feed-uri în formaturi diferite (CSV, XML, JSON, uneori HTML crawling), (2) deduplicare inteligentă — același produs listat de 5 magazine sub nume ușor diferite, (3) viteză pe mobil unde 80% din trafic vine.

Constrângerea reală: budget de infrastructură de €80-100/lună. Nu AWS, nu Google Cloud. Un VPS Hetzner cu MariaDB și Docker. Fiecare decizie de arhitectură trebuia să se încadreze în acel buget, inclusiv crawling-ul zilnic care procesează 2-3 milioane de rânduri.

Decizii tehnice cheie

1. MariaDB + indici compuși pentru query-uri de comparație

Am ales MariaDB în loc de PostgreSQL pentru cost: MariaDB pe Hetzner VPS cu 16GB RAM poate procesa query-uri de comparație pe 750K produse sub 100ms cu indici compuși corect construiți. Index-ul cheie: (category_id, is_active, offer_count) — permite filtrarea pe categorie cu produse care au oferte active într-un singur index scan.

2. Deduplicare prin hash produs + fuzzy matching

Același produs apare sub 5 nume diferite în feed-uri. Prima etapă: hash normalizat (brand + model + capacitate) pentru potrivire exactă. A doua etapă: algoritm Levenshtein pe nume normalizate pentru potrivire aproximativă. Rata de deduplicare: 92% automat, 8% verificare manuală prin dashboard admin.

3. Crawler async cu Celery + rate limiting per magazin

Ingest-ul zilnic rulează pe Celery workers cu rate limiting per magazin (respectăm robots.txt și nu trimitem mai mult de 1 request/secundă per domeniu). Feed-urile complete (CSV/XML) se descarcă o dată pe zi la 2AM. Update-uri de preț incremental la fiecare 4 ore pentru top 1000 produse (cele mai căutate). Timp total ingest: 3-4 ore pe VPS.

Provocări întâlnite

Provocarea 1: Feed-uri cu formaturi invalide

Aproximativ 15% din feed-uri aveau formaturi invalide: coloane lipsă, encoding greșit (Windows-1252 în loc de UTF-8), prețuri cu virgulă în loc de punct. Soluție: layer de normalizare care detectează encoding-ul automat (chardet), parse defensiv cu fallback la coloane după poziție, și alertare automată când un feed nu parsează corect 2 zile la rând.

Provocarea 2: Căutare full-text pe 750K produse sub 200ms

MariaDB FULLTEXT index pe câmpurile de căutare era lent (400-800ms) pentru cuvinte parțiale. Soluție: Meilisearch ca layer de căutare — index sincronizat din MariaDB la fiecare ingest, căutare instantă sub 50ms. Meilisearch rulează în container Docker pe același VPS, consumă sub 2GB RAM.

Provocarea 3: Afiliere 2Performant cu tracking conversii

Monetizarea principală e afilierea prin 2Performant. Provocarea: link-urile de afiliere trebuie să trackeze și conversia pe server (nu cookie-only), pentru că mulți utilizatori au ad-blockere. Soluție: redirect server-side prin endpoint /go/{product_id} care înregistrează click-ul în DB înainte de redirect. Conversia se confirmă prin postback de la 2Performant.

Lecții pentru proiecte similare

1. MariaDB + indici compuși bat PostgreSQL pe cost pentru workload-uri de comparație cu peste 500K rânduri pe un singur VPS. Rezervă PostgreSQL pentru proiecte cu query-uri complexe OLAP.
2. Meilisearch ca layer de căutare elimină problema full-text pe baze mari. Sub 50ms pentru 750K produse, setup în Docker în 10 minute.
3. Crawling cu rate limiting per domeniu respectă robots.txt și menține relații bune cu magazinele partenere. Fără rate limiting → IP ban → date învechite.
4. Deduplicarea e 80% din valoarea unui comparator. Fără deduplicare, utilizatorul vede același produs de 5 ori și pierde încrederea.
5. Afiliere server-side tracking supraviețuiește ad-blocker-elor. Cookie-only = 30-40% pierdere conversie în 2026.

Citește în continuare

• Servicii: Dezvoltare web
• Audit performanță magazin online
• Studiu de caz: La Iancu