Make.com a scala: pattern per ridurre costi operativi e migliorare la latency

Make.com è uno strumento eccezionale per chi inizia, ma diventa un costo significativo quando si supera una certa soglia. Tra le aziende ecommerce italiane mid-market che gestiscono ordini, magazzino, customer service e logistica via Make, è normale arrivare nel giro di un paio d’anni a sessanta-ottanta scenari attivi e un consumo mensile sopra il milione di operations. A quel punto il piano abbonamento diventa visibile a bilancio, e — più importante — la latency di scenari critici come la conferma ordine inizia a degradare.

Questo articolo descrive l’approccio che applico durante un audit Make su un account a scala. Non sono best practice teoriche: sono pattern che ho usato di recente in un intervento su un account ecommerce con sessantatré scenari attivi nell’area B2B distribution, con l’obiettivo di tagliare il consumo di operations senza perdere reliability. Il risultato è stato un calo da circa 2,5 milioni a 1,5 milioni di operations al mese — circa il 40% in meno — e una latency end-to-end dello scenario “Ordine Confermato” portata stabilmente sotto i due secondi.

Da dove partire: la mappa dei consumi

Il primo errore in un audit Make è guardare gli scenari uno a uno. Si tende a ottimizzare quelli che si conoscono meglio, che spesso non sono quelli che consumano di più. Il primo passo che faccio sempre è generare una mappa di consumo operations per scenario, ordinata in modo decrescente, sulle ultime quattro settimane.

In quasi tutti gli audit ho visto la stessa distribuzione: il 70-80% delle operations è concentrato in cinque-otto scenari. Sono quasi sempre scenari triggerati ad alta frequenza (webhook, polling minuto, pg_cron) e con lookup esterni dentro al ciclo. Il resto degli scenari, pur essendo numerosi, conta poco a livello di costo. Concentrare l’effort di refactoring solo sui top-consumer porta il maggior ritorno.

Pattern 1: Data Store al posto del Sheet lookup

Il pattern più frequente che trovo in account scalati male è l’uso di Google Sheets come database di lookup. Tipicamente: lo scenario riceve un webhook ordine, fa un “Search Rows” su uno Sheet per recuperare metadati prodotto (categoria, fornitore, regola spedizione), e procede. È una soluzione che funziona benissimo finché lo Sheet ha qualche centinaio di righe e lo scenario gira poche volte al giorno. Su volumi reali — diecimila righe Sheet, duemila trigger al giorno — diventa il singolo punto più costoso del setup.

Il refactoring è sostituire lo Sheet lookup con un Data Store nativo di Make. Il Data Store è progettato esattamente per questo: lookup per chiave, costo operations marginale, latency in millisecondi invece di secondi. Nell’audit citato, la sostituzione di sette Sheet lookup ricorrenti con Data Store ha tagliato circa 400.000 operations al mese e ha ridotto la latency media dei trigger interessati dell’ordine del 60-70%.

C’è un trade-off importante: lo Sheet è human-readable, il Data Store no. Per mantenere il vantaggio operativo dello Sheet — il fatto che il team operations può aggiornarlo a mano — la soluzione che ho adottato è uno scenario di sincronizzazione bidirezionale Sheet → Data Store ogni quindici minuti. Lo Sheet resta la fonte editabile, il Data Store è la copia veloce usata in runtime.

Pattern 2: sequential processing su webhook ad alto volume

Su un webhook che riceve cento eventi al minuto durante i picchi promozionali, il comportamento default di Make è eseguire i bundle in parallelo. È efficiente, ma su scenari che scrivono su risorse condivise (un counter, uno stato ordine, una riga di stock) genera race condition: due esecuzioni concorrenti leggono lo stesso valore, lo modificano, e l’ultima sovrascrive la prima. Il bug è intermittente, difficile da riprodurre e quasi sempre scoperto dopo un’incident con un cliente.

Il pattern che applico è forzare l’elaborazione sequenziale dei bundle sul webhook critico, accettando il costo in throughput in cambio di consistency. In Make si fa configurando il webhook a processare un bundle alla volta e dimensionando un piccolo buffer a monte. Per i webhook dove la sequenzialità non è negoziabile (es. eventi di stato ordine), questo pattern ha eliminato un’intera classe di bug che prima il team trattava manualmente con correzioni in customer service.

Pattern 3: monitoring custom oltre la Run History

La Run History di Make è utile per debug ad-hoc ma non è un sistema di monitoring. Non ha alerting, non ha dashboard di trend, non distingue facilmente tra failure transitori e degradazioni strutturali. Per qualsiasi account che gira sopra il milione di operations al mese, vale la pena costruire un layer di monitoring custom.

Il pattern minimo che implemento è uno scenario meta che, a intervalli regolari, interroga la Make API per recuperare failure rate, queue depth e tempo medio di esecuzione degli scenari critici. I dati finiscono in una Sheet o in un Data Store, e su soglie predefinite parte un alert Slack o email. Sembra ridondante, ma è ciò che permette di accorgersi della degradazione un giorno prima che chiami il cliente.

Pattern 4: latency budget per scenari critici

Per uno scenario customer-facing come “Ordine Confermato” — quello che parte sul webhook Shopify e deve produrre la conferma email, il messaggio WhatsApp, il record CRM e il tag operativo — il budget di latency deve essere esplicito. La domanda da porsi non è “quanto ci mette in media”, ma “quanto ci mette nel 95° percentile in giornata di picco”. L’esperienza utente si rompe sui picchi, non sulle medie.

Per riportare uno scenario di questo tipo stabilmente sotto i due secondi, le leve da usare sono quattro. Eliminare ogni HTTP call non strettamente necessaria nel percorso sincrono, spostandola in uno scenario figlio asincrono. Sostituire Sheet lookup con Data Store come descritto sopra. Eliminare i moduli “router” inutili che il team aveva accumulato in fase di sviluppo. Raggruppare le scritture su una stessa risorsa in un singolo modulo bulk dove l’API lo supporta.

Il framework di audit in cinque passaggi

L’approccio che applico è strutturato. Prima settimana: mappa dei consumi, identificazione dei top-consumer, baseline di latency. Seconda settimana: refactoring dei lookup ricorrenti verso Data Store. Terza settimana: introduzione del monitoring layer e dei sequential webhook dove servono. Quarta settimana: ottimizzazione latency degli scenari critici e cleanup degli scenari obsoleti. La quinta è dedicata a documentazione e training del team interno, perché un audit che non lascia capacità di mantenimento è un audit che si paga due volte nel giro di un anno.

Take-away

Tre punti chiave per chi sta valutando un intervento di ottimizzazione su un account Make scalato. Primo: il costo non si taglia uniformemente, si taglia sui top consumer. Identificarli prima di toccare codice è metà del lavoro. Secondo: Data Store vs Sheet è la singola decisione architetturale che produce il maggior risparmio di operations su account ecommerce; vale quasi sempre la pena fare il refactoring. Terzo: la latency è un problema di percentili, non di medie. Se non state misurando il p95 dei vostri scenari critici, state ottimizzando alla cieca. Un audit ben fatto, su un account sopra il milione di operations al mese, restituisce tipicamente un payback inferiore al trimestre considerando solo il risparmio diretto sul piano Make, senza contare le ore liberate al team operations dal monitoring proattivo.