WooCommerce e gestione stock: quando il database non regge i picchi di vendita (e come non farsi trovare impreparati)

Lo scenario è classico. Un e-commerce con 4.000 prodotti, traffico normale di 200 ordini al giorno, tutto che fila liscio per undici mesi. Poi arrivano i saldi: il primo giorno il traffico triplica, il checkout impiega 8 secondi a caricare, e una certa percentuale di clienti abbandona il carrello. Il server non è caduto, PHP non ha errori, la page cache sta lavorando. Il colpevole è il database — più precisamente, la gestione stock che su WooCommerce fa un numero di query proporzionale al numero di prodotti e alla concorrenza.

Il problema non è WooCommerce in sé: è che la gestione stock nativa è pensata per store piccoli e medi. Ogni volta che un prodotto viene aggiunto al carrello, WooCommerce ricalcola la disponibilità facendo query su wp_postmeta — una tabella che su store con migliaia di prodotti può arrivare a milioni di righe. Sotto carico normale non si nota. Sotto un picco, i lock di tabella si sommano e il database diventa il collo di bottiglia.

Perché wp_postmeta diventa il problema

WordPress memorizza i dati dei prodotti WooCommerce come post meta: ogni attributo (prezzo, stock, SKU, peso) è una riga in wp_postmeta con una chiave e un valore. Un prodotto con 15 attributi genera 15 righe. Su 4.000 prodotti sono 60.000 righe solo per i meta base — e molti store ne accumulano molte di più con plugin di attributi personalizzati, varianti, campi avanzati.

Quando WooCommerce deve mostrare la disponibilità di un prodotto, fa una query su wp_postmeta filtrando per la chiave _stock. Sotto carico normale, MySQL serve la query in pochi millisecondi. Ma quando 200 visitatori contemporanei aggiungono prodotti al carrello durante un salto, le stesse query si moltiplicano e MySQL inizia a mettere lock di tabella. Il risultato è quello che vediamo nei log: tempi di query che passano da 5ms a 800ms, e un checkout che per l'utente sembra bloccato.

Puoi vedere quali query stanno rallentando il database abilitando il query log di MySQL:

-- Abilita il log delle query lente (sopra 1 secondo)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Trova le query più lente su wp_postmeta
SELECT * FROM wp_postmeta
WHERE meta_key = '_stock'
ORDER BY meta_id DESC
LIMIT 100;

-- Conta quante righe di meta ha ogni prodotto
SELECT post_id, COUNT(*) AS meta_count
FROM wp_postmeta
GROUP BY post_id
ORDER BY meta_count DESC
LIMIT 20;

Le tre leve che tengono in piedi lo stock sotto carico

Prima di pensare a cambiare piattaforma, ci sono tre interventi che risolvono la maggior parte dei casi. Il primo è l'object cache Redis: intercetta le query ripetute su wp_postmeta e serve il risultato dalla memoria invece di rifare la stessa domanda a MySQL. Su un WooCommerce con Redis configurato bene, il TTFB del checkout sotto carico può scendere del 40-60% — non perché il database sia più veloce, ma perché 35 query su 40 non ci arrivano più.

Il secondo è l'indicizzazione. WooCommerce crea indici su wp_postmeta per alcune chiavi, ma non per tutte quelle che contano sotto carico. Puoi aggiungere un indice sulla chiave _stock per accelerare le query di disponibilità:

-- Aggiungi un indice su meta_key per accelerare le query di stock
ALTER TABLE wp_postmeta ADD INDEX wp_postmeta_meta_key (meta_key);

-- Indice composto per le query di disponibilità
ALTER TABLE wp_postmeta ADD INDEX wp_postmeta_stock (meta_key, meta_value);

-- Verifica che l'indice sia usato (EXPLAIN)
EXPLAIN SELECT * FROM wp_postmeta
WHERE meta_key = '_stock' AND meta_value > 0;

Il terzo intervento è il caching a livello di pagina per le parti non personalizzate. Le pagine di categoria e prodotto, se non mostrano stock in tempo reale, possono essere servite dalla page cache. Il problema è che molti store mostrano la disponibilità su ogni card di prodotto — e questo rende la pagina dinamica. Una scelta di design è nascondere il contatore esatto e mostrare solo 'disponibile' o 'esaurito', permettendo alla page cache di servire la pagina intera.

Quando il database non basta più

Ci sono casi in cui le tre leve non bastano. Lo vediamo su store con 20.000+ prodotti, cataloghi con varianti complesse, integrazioni ERP che sincronizzano lo stock ogni pochi minuti, o e-commerce B2B dove il prezzo cambia per cliente. In questi scenari la gestione stock nativa di WooCommerce diventa un limite strutturale, e conviene spostare la logica di inventario su un sistema esterno.

L'architettura tipica è un sistema di inventory management separato (un ERP, un PIM, o un servizio dedicato) che comunica con WooCommerce via API. Il frontend non legge più lo stock dal database WordPress: lo chiede al sistema esterno, che serve il dato dalla sua memoria ottimizzata. WooCommerce resta il frontend di checkout, ma la fonte di verità per stock e disponibilità è altrove.

Non è una scelta da prendere alla leggera. Un sistema esterno aggiunge complessità, un punto di failure in più, e richiede sincronizzazione bidirezionale. Ma per store che hanno superato il limite del database WordPress, è la differenza tra un e-commerce che scala e uno che crolla proprio quando potrebbe vendere di più.

Il test che ti dice se sei pronto per i saldi

Il modo migliore di sapere se la gestione stock reggerà un picco è simularlo prima che arrivi. Un test di carico sul checkout con 200 utenti simultanei ti dice in mezz'ora se il database tiene o se devi intervenire. Non aspettare il Black Friday per scoprirlo.

# Test di carico sul checkout con Apache Bench
# 200 richieste concorrenti sulla pagina carrello
ab -n 200 -c 20 -H "Cookie: wordpress_logged_in=test" \
  https://www.example.com/carrello/

# Guarda il 'Time per request' e gli errori
# Sotto 500ms = ok per la maggior parte degli store
# Sopra 1s con errori = il database sta soffrendo

# Ripeti sulla pagina di un prodotto singolo
ab -n 200 -c 20 https://www.example.com/prodotto-test/

La gestione stock è uno di quei problemi che non si vede finché non fa male. Sotto carico normale tutto funziona; sotto un picco, il database diventa il collo di bottiglia e il checkout diventa il punto dove perdi fatturato. Un audit WooCommerce che include un test di carico sul checkout è il modo più concreto di sapere se sei pronto per il prossimo salto — o se devi intervenire prima.