Architettura e-commerce scalabile: il case study Initpc

Ci sono clienti che si seguono per un progetto e clienti che si seguono per vent'anni. Initpc.it appartiene alla seconda categoria: un e-commerce di materiale per ufficio, cancelleria, articoli per la scuola e informatica che TN Solutions accompagna dal 2006, quando era un negozio online come tanti, fino a oggi, con oltre 280.000 prodotti a catalogo, più di un milione di immagini e una ricerca che risponde su tutto questo in tempo utile.

Non è un caso studio su una singola tecnologia. È il racconto di un'architettura e-commerce scalabile costruita per gradi, sostituendo cinque piattaforme di vendita senza mai perdere il filo dei sedici anni di indirizzi che i motori di ricerca conoscevano, e portando dentro, una alla volta, le cose che un negozio di quella scala richiede: server virtualizzati, cache a più livelli, un motore di ricerca dedicato, un gestionale che governa fornitori e magazzini, un'intelligenza artificiale che scrive le schede prodotto.

Questa pagina è il quadro d'insieme: contesto, sfida, scelte architetturali, problemi e risultati. Per ogni tema che merita una lettura a sé abbiamo scritto un approfondimento dedicato, linkato lungo il testo e raccolto in fondo.

Il contesto: un negozio online che è cresciuto per vent'anni

Initpc.it vende a privati e ad aziende, con un catalogo che copre dalla penna a sfera al toner, dalla carta per ufficio agli articoli regalo. Il catalogo non lo costruisce a mano: lo alimentano più fornitori e magazzini, ognuno con i suoi listini, i suoi codici, le sue disponibilità. È questo, prima ancora dei volumi di traffico, che rende il progetto diverso da un e-commerce "da vetrina": il sito è la punta visibile di un sistema che ogni giorno riceve dati, li corregge, decide cosa pubblicare e a quale prezzo, e li spinge verso il negozio e i marketplace.

La nostra collaborazione tecnica è iniziata nel 2006 e non si è mai interrotta. In vent'anni abbiamo progettato e sviluppato i sistemi su cui il negozio gira, seguendolo attraverso cinque piattaforme di vendita: osCommerce, Zen Cart, Magento, Magento 2 e infine WooCommerce, che è la piattaforma attuale. Ogni passaggio è stato una migrazione vera, con dati, immagini, clienti e — soprattutto — indirizzi da portare dall'altra parte.

La sfida: scala, storia e controllo

Le difficoltà di un e-commerce grande non sono la versione ingrandita di quelle di un e-commerce piccolo. Cambiano natura. Un catalogo di qualche migliaio di articoli si cerca con la funzione integrata della piattaforma; con oltre 280.000 prodotti la stessa funzione collassa e trascina con sé il database. Un listino si importa con un plugin; più listini di fornitori diversi, con codici in conflitto e disponibilità che cambiano di continuo, richiedono un gestionale. Le schede prodotto di un piccolo negozio si scrivono; a 160.000 e poi 280.000 articoli si progettano, si generano e si controllano.

A questo si aggiunge la storia: sedici anni di URL, generati da cinque piattaforme con cinque logiche diverse, che i motori di ricerca hanno indicizzato e altri siti hanno linkato. Ogni migrazione poteva disperderli. E si aggiunge il controllo: la scelta, ripetuta nel tempo, di non affidare a servizi esterni ciò che potevamo costruire e mantenere noi — dal repricing per i marketplace alla generazione delle schede con l'AI, fino al monitoraggio del perimetro di rete.

L'architettura in sintesi

L'architettura attuale è a strati, ognuno con un compito e ciascuno sostituibile senza toccare gli altri. Il fondamento è una piattaforma di virtualizzazione Proxmox VE su Ubuntu Server: i ruoli dell'e-commerce — frontend web, database, cache, ricerca, servizi di supporto — vivono in macchine virtuali separate, così un carico anomalo su un componente non affama gli altri e ogni strato si può dimensionare per conto suo.

Strato	Componenti	Ruolo
Perimetro	pfSense, Hector LIS	Firewall e segmentazione di rete; rilevamento intrusioni e monitoraggio del traffico
Ingresso	HAProxy	Bilanciamento del traffico e terminazione TLS
Cache HTTP	Varnish	Serve dalla memoria le pagine che non devono rigenerarsi a ogni visita
Applicazione	WordPress + WooCommerce	Il negozio: catalogo, carrello, ordini, area clienti
Cache applicativa	Redis	Object cache e sessioni, per non ripetere le stesse query al database
Ricerca	Elasticsearch (ElasticPress), in Docker	L'indice su cui gira la ricerca del catalogo e l'autosuggest
Dati	MariaDB	Il database dell'e-commerce
Governo del catalogo	Gestionale proprietario TN Solutions	Fornitori, magazzini, normalizzazione, pubblicazione, prezzi, marketplace e repricing
Contenuti	Hector AI	Normalizzazione dei dati di prodotto e generazione controllata delle schede

Come i pezzi stanno insieme, cosa succede quando uno di essi cade e come si scala ogni strato lo spieghiamo nell'approfondimento sull'architettura infrastrutturale dell'e-commerce Initpc.

I problemi principali che abbiamo affrontato

La ricerca che collassava. Il motore integrato della piattaforma interroga il database con query costose su prodotti e metadati: sotto un catalogo di questa dimensione i risultati arrivavano lenti e poco pertinenti, e il carico rallentava il resto del sito. Abbiamo spostato la ricerca su Elasticsearch, in un contenitore Docker, collegandola a WooCommerce tramite ElasticPress: indice separato, sincronizzazione continua, autosuggest sul campo di ricerca. Ne parliamo in Elasticsearch e la ricerca su oltre 280.000 prodotti.

Cinque piattaforme, sedici anni di indirizzi. Ogni piattaforma aveva scritto gli URL a modo suo. Prima di ogni migrazione abbiamo censito gli indirizzi esistenti — log, Search Console, sitemap precedenti, backlink — e costruito le regole di redirect, i canonical e le sitemap perché il posizionamento non si disperdesse. Il metodo è nell'approfondimento sulla migrazione SEO di un e-commerce con 16 anni di URL.

Listini che non parlano la stessa lingua. Fornitori e magazzini diversi, formati diversi, codici che si sovrappongono, disponibilità che cambiano. Il gestionale che abbiamo sviluppato normalizza i dati, applica le regole di pubblicazione, aggiorna prezzi e disponibilità verso il sito e i marketplace, e gestisce gli errori invece di lasciarli passare. Lo raccontiamo in catalogo, magazzini e gestionale proprietario.

Schede prodotto povere, e troppe per scriverle a mano. Quando il catalogo contava circa 160.000 articoli, la stima per generare le schede con API di intelligenza artificiale commerciali superava i 30.000 euro. Abbiamo scelto di costruire la pipeline in casa con Hector AI, sostenendo solo i costi di energia e server: normalizzazione degli attributi, generazione di titoli, descrizioni e keywording, controlli prima della pubblicazione. Il caso è in Hector AI e le schede prodotto.

Prestazioni su un sito che cambia ogni giorno. Le pagine di un catalogo così vasto non si possono pre-generare tutte, né servire ogni volta dal database: la combinazione di Varnish e Redis, insieme a un lavoro progressivo su immagini, rendering e metriche — prima sul desktop, poi sul mobile, con Lighthouse e Chrome DevTools — è ciò che tiene le pagine reattive. I test reali di Google PageSpeed Insights, con il desktop che supera i Core Web Vitals e il mobile ancora in lavorazione, sono in performance e Core Web Vitals dell'e-commerce.

Le tecnologie

Proxmox VE e Ubuntu Server per la virtualizzazione; HAProxy, Varnish e Redis per ingresso e cache; WordPress e WooCommerce come piattaforma di vendita; MariaDB per i dati; Elasticsearch con ElasticPress, in Docker, per la ricerca; pfSense e Hector LIS per perimetro e monitoraggio; il gestionale proprietario TN Solutions per il catalogo, i marketplace e il repricing; Hector AI per la qualità dei dati e le schede. Tecnologie open dove esistono, software nostro dove il mercato offriva solo abbonamenti che avremmo pagato per sempre senza controllarli.

I risultati

• Un e-commerce con oltre 280.000 prodotti e più di un milione di media che resta gestibile da un'azienda, non da un reparto IT.
• Una ricerca che risponde su tutto il catalogo, con suggerimenti mentre si digita, senza pesare sul database.
• Cinque migrazioni di piattaforma in sedici anni con gli indirizzi storici mappati e reindirizzati, invece che perduti.
• Schede prodotto generate e controllate con Hector AI per circa 160.000 articoli, con un aumento rilevante di visibilità organica e traffico nelle settimane successive e una migliore indicizzazione di categorie e brand di coda lunga.
• Prezzi e disponibilità allineati fra fornitori, sito e marketplace da un unico gestionale, con un repricing proprietario che tiene conto di margine e commissioni.
• Un'infrastruttura in cui ogni strato si può fermare, aggiornare o ingrandire senza fermare il negozio.

Problema → soluzione

Problema	Soluzione	Approfondimento
Un solo server per tutto, senza margini di crescita	Proxmox VE con VM separate per ruolo; HAProxy, Varnish e Redis davanti a WooCommerce	Architettura infrastrutturale
Ricerca lenta e irrilevante, database sotto carico	Elasticsearch in Docker via ElasticPress, indice sincronizzato, autosuggest	Elasticsearch e ricerca
Sedici anni di URL da cinque piattaforme diverse	Censimento, mappatura, redirect 301 a pattern e puntuali, canonical, sitemap	Migrazione SEO
Listini eterogenei di più fornitori e magazzini	Gestionale proprietario: normalizzazione, regole di pubblicazione, sincronizzazioni, error handling	Gestionale e magazzini
Vendita sui marketplace con margini da difendere	Pubblicazione multicanale e repricing proprietario (margine, commissioni, disponibilità)	Nel caso del gestionale
Schede prodotto povere, impossibili da scrivere a mano	Hector AI: normalizzazione degli attributi, generazione controllata, verifiche a lotti	Hector AI e schede prodotto
Perimetro esposto di un sito che vende 24 ore su 24	pfSense per la segmentazione, Hector LIS per rilevamento e monitoraggio	Nell'architettura infrastrutturale
Pagine pesanti su un catalogo in continuo cambiamento	Cache a più livelli e ottimizzazione progressiva di immagini e rendering	Performance e Core Web Vitals

Produzione, sviluppo, sperimentazione

Un case study onesto distingue ciò che gira da ciò che stiamo costruendo.

In produzione oggi: WooCommerce, la ricerca su Elasticsearch tramite ElasticPress, l'infrastruttura Proxmox con HAProxy, Varnish, Redis e MariaDB, il perimetro pfSense con Hector LIS, il gestionale proprietario con pubblicazione multicanale e repricing, le schede generate con Hector AI.

In sviluppo: un nuovo motore di ricerca proprietario, sempre su Elasticsearch in Docker ma con indice e ranking progettati da noi invece che mediati da un plugin, pensato per usare gli attributi distillati da Hector AI; e una versione commerciale di Hector AI con un operatore umano nel ciclo, per assistere i clienti del negozio.

In sperimentazione futura: un e-commerce proprietario, fuori dai confini di WooCommerce, che inizieremo a sperimentare da dicembre 2026. Non è in produzione e non lo presentiamo come tale: lo scriviamo qui perché è la direzione naturale di vent'anni di lavoro su questo progetto.

Conclusioni

Initpc.it non è cresciuto perché a un certo punto qualcuno ha comprato una piattaforma più grande. È cresciuto perché ogni volta che un pezzo arrivava al limite — il server, la ricerca, il modo di gestire i listini, il modo di scrivere le schede — quel pezzo è stato sostituito con qualcosa progettato per la scala successiva, senza buttare via il resto e senza perdere la storia accumulata. È lo stesso metodo che applichiamo sui progetti dei nostri clienti: lo raccontiamo nella pagina sullo sviluppo e-commerce e progettazione e, per la parte infrastrutturale, nei servizi di virtualizzazione server e assistenza server aziendali.

Chi ha un catalogo che sta diventando ingestibile, una migrazione davanti o una ricerca che non regge più, in questo caso studio trova un precedente reale. Gli approfondimenti qui sotto entrano nel dettaglio di ogni tema.