Architetture Cloud-Native per Odoo 19: scalare oltre i 100 utenti simultanei

Se lavori con Odoo da abbastanza tempo, conosci bene il "muro dei 100 utenti". Fino a quella soglia, un'infrastruttura monolitica ben dimensionata riesce a fare il suo dovere. Ma quando si supera quel limite, le regole del gioco cambiano: i worker HTTP si saturano, i lock sul database si moltiplicano e l'interfaccia utente inizia a rallentare vistosamente.

Con Odoo 19, due fattori aggravano questo scenario rispetto alle versioni precedenti: l'utilizzo più intensivo del bus di notifiche in tempo reale, che alimenta aggiornamenti live su listini, disponibilità e stati degli ordini, e la presenza di funzionalità AI opzionali (assistenti nel CRM, suggerimenti automatici, elaborazioni in background) che, se attivate, aggiungono carico computazionale non trascurabile. Non si tratta di un cambiamento radicale rispetto a Odoo 17 o 18, ma di una pressione crescente che rende l'approccio Cloud-Native sempre più rilevante per chi gestisce ambienti enterprise.

In Unitiva affrontiamo quotidianamente sfide architetturali complesse. Non ci limitiamo ad "aggiungere server", ma disegniamo infrastrutture che respirano insieme all'azienda. Ecco come affrontiamo la scalabilità per i progetti Enterprise.

1. Disaccoppiare per scalare: l'architettura "Stateless"

Il primo passo per superare i limiti fisici di una singola macchina è rendere i nodi applicativi intercambiabili. In una configurazione Cloud-Native, le istanze di Odoo devono essere stateless, ovvero prive di stato locale.

All'atto pratico, questo si traduce in due interventi strutturali:

1. Filestore su Object Storage. Gli allegati non risiedono più sul disco del server, ma su soluzioni esterne compatibili con il protocollo S3. Questo permette a più istanze di Odoo di accedere simultaneamente agli stessi documenti senza conflitti o problemi di sincronizzazione.
2. Gestione Sessioni con Redis. In Odoo 19, Redis funge da message broker per le notifiche in tempo reale e memorizza le sessioni utente. In questo modo, se un container viene ricreato dal bilanciatore di carico, l'utente non viene disconnesso. Vale la pena precisare che Redis non è una novità assoluta nell'ecosistema Odoo, ma il suo ruolo si è consolidato e allargato nel corso delle ultime versioni major.

2. Il collo di bottiglia è (quasi) sempre il Database

Scalare la parte applicativa è relativamente semplice; scalare il database è un'arte. Quando oltre 100 utenti confermano ordini, registrano pagamenti e movimentano magazzini in simultanea, PostgreSQL viene letteralmente inondato di connessioni.

Connection Pooling con PgBouncer. In scenari ad alta concorrenza, non facciamo mai collegare i worker di Odoo direttamente a PostgreSQL. Inseriamo PgBouncer in modalità transaction pooling (e non session pooling, che causerebbe problemi di compatibilità con le prepared statements di Odoo)  per mantenere attive e riutilizzare un numero ristretto di connessioni fisiche, abbattendo drasticamente il consumo di RAM e lo spreco di cicli CPU.

Separazione del carico con Read Replicas. Questa tecnica merita una precisazione importante: Odoo non gestisce nativamente il routing lettura/scrittura verso repliche PostgreSQL. Implementare questa separazione richiede quindi un layer esterno dedicato, tipicamente pgpool-II o un proxy applicativo, oppure, nella soluzione che preferiamo, indirizzare le query analitiche verso una replica accessibile esclusivamente da strumenti BI separati come Metabase o Grafana. In questo modo il nodo Master rimane libero di processare le scritture senza interferenze, e si evita la complessità di dover intercettare e smistare le query all'interno dell'ORM di Odoo.

3. Isolare le risorse: i Background Job e l'Audit

Odoo 19 ha spinto molto sull'automazione silente, ma ogni elaborazione ha un costo computazionale.

In progetti con requisiti severi — come quello realizzato per InnovaVector (gestione lotti e Audit Trail in ambito farmaceutico GMP) o per INCAL Agricola (Food Manufacturing) — il sistema deve validare centinaia di lotti, controllare scadenze e generare log di tracciabilità massivi in background. Se queste elaborazioni condividono le stesse risorse di chi sta compilando una bolla al terminale logistico, l'intero sistema ne risente.

La soluzione è dedicare istanze specifiche — con il parametro --max-cron-threads configurato opportunamente — esclusivamente ai processi Cron e alle code di lavoro. Gli operatori in magazzino non si accorgeranno mai dell'immenso lavoro di elaborazione che avviene dietro le quinte.

4. Monitoraggio proattivo: osservabilità moderna

Quando distribuisci Odoo su un cluster di container, leggere i file di log tramite terminale SSH è impensabile. Per progetti di questa taglia implementiamo uno stack di osservabilità moderno come la suite LGTM (Loki, Grafana, Tempo, Mimir) tramite OpenTelemetry.

Un approccio consulenziale serio non aspetta che sia il cliente ad aprire un ticket per segnalare una lentezza: i nostri cruscotti ci avvisano in tempo reale se una specifica query sta causando lock anomali o se una determinata automazione sta saturando i worker.

Scegliere il livello di complessità giusto

Un'architettura Cloud-Native su Kubernetes offre scalabilità e resilienza eccezionali, ma porta con sé una complessità operativa significativa: gestione dei certificati, networking, storage persistente, pipeline di upgrade. Non è la risposta giusta per tutti.

Per molte aziende di medie dimensioni, una soluzione basata su Docker Compose su VM ridondante con HAProxy come bilanciatore offre la maggior parte dei benefici — statelessness, isolamento dei worker, scalabilità orizzontale — con una frazione della complessità gestionale. Kubernetes diventa la scelta naturale quando si hanno volumi utenti molto elevati, requisiti di disponibilità stringenti (SLA 99.9%+) o un team DevOps interno in grado di gestirne il ciclo di vita.

Il nostro compito, come partner, è proporre il livello architetturale proporzionato al reale fabbisogno del cliente — non la soluzione più sofisticata in assoluto.

Il vero ROI di una progettazione su misura

Passare a un'architettura distribuita per Odoo richiede competenze trasversali e un setup iniziale rigoroso tramite Infrastructure as Code (Terraform, Ansible) e pipeline CI/CD per garantire aggiornamenti senza downtime.

Il ritorno sull'investimento, però, è concreto: riduzione drastica dei disservizi durante i picchi operativi, sicurezza del dato e — soprattutto — un ERP che smette di essere un freno tecnico per diventare il vero motore della crescita aziendale.

In Unitiva lavoriamo affinché la tecnologia complessa risulti invisibile a chi la usa: l'unico metro di giudizio deve essere la fluidità con cui l'azienda riesce a scalare il proprio business.