Software scalabile: come progettarlo dall'inizio

"Il software deve essere scalabile" è una frase che si sente in ogni kickoff, ma spesso senza sapere cosa significhi davvero. Scalabilità non è una proprietà magica che si ottiene mettendo il sistema "sul cloud": è il risultato di decisioni architetturali precise prese nei momenti giusti.

In questa guida vediamo cosa significa davvero scalabilità, quali decisioni la abilitano dall'inizio, e quali errori tipici la rendono impossibile senza riscritture costose.

I quattro assi di scalabilità

Un software può aver bisogno di scalare lungo quattro assi distinti:

1. Utenti contemporanei

Numero di persone che usano il sistema nello stesso momento. Da 10 a 10.000 simultanei richiede architetture molto diverse.

2. Volumi di dati

Quanto dato il sistema gestisce. Da 1 GB a 100 TB cambia profondamente le scelte di storage e di indicizzazione.

3. Velocità di scrittura

Numero di operazioni di scrittura al secondo. Sistemi che ricevono migliaia di transazioni/sec hanno requisiti completamente diversi da sistemi che ne ricevono una manciata.

4. Geografia

Utenti distribuiti su più regioni del mondo richiedono CDN, database replicati, latenze controllate.

Capire quali assi conteranno per il tuo caso è il primo passo per progettare bene. Ottimizzare per assi che non ti riguardano è over-engineering.

Le 6 decisioni che abilitano la scalabilità

Decisioni architetturali da prendere bene fin dall'inizio. Sono difficili da cambiare dopo.

1. Separazione frontend / backend

Frontend e backend devono essere disaccoppiati, comunicando via API ben definite. Permette di scalarli indipendentemente, sostituirne uno senza toccare l'altro, deployare a velocità diverse.

2. Stato applicativo fuori dal server

I server applicativi devono essere "stateless": qualunque server può rispondere a qualunque richiesta. Lo stato (sessioni, cache temporanee) vive in storage condivisi (cache distribuita, database).

Questo permette di mettere N server dietro un load balancer e farli lavorare in parallelo.

3. Database scelto in base al pattern d'uso

Database SQL e NoSQL non sono interscambiabili. La scelta dipende dal pattern d'uso: scritture massive vs letture massive, dati strutturati vs documentali, consistenza forte vs eventualmente consistente.

Sbagliare la scelta del database è uno degli errori più costosi, perché correggerla richiede migrazione di tutti i dati.

4. Operazioni asincrone via code di lavoro

Operazioni che richiedono tempo (invio email, generazione report, elaborazione media) devono uscire dal flusso sincrono della richiesta utente. Vanno in code di lavoro processate da worker dedicati.

Permette al frontend di rispondere veloce all'utente e al backend di processare il lavoro in modo elastico.

5. Caching multi-livello

Cache HTTP davanti al server, cache applicativa nel server, cache di database per le query ripetute. Tre livelli di defense-in-depth contro carico inutile.

Il caching ben fatto può ridurre il carico di un'app del 60-80% senza cambiare logica di business.

6. Osservabilità fin dall'inizio

Senza monitoring, scaling è impossibile: non sai cosa è lento, dove sono i bottleneck, quanto traffico stai gestendo. Logging strutturato + metriche + tracing distribuito sono prerequisiti, non aggiunte successive.

Tabella decisioni-impatto

La regola: tutto ciò che riguarda architettura strutturale va deciso bene all'inizio. Tutto ciò che è layer di ottimizzazione può essere aggiunto progressivamente.

Anti-pattern che bloccano la scalabilità

Tre pattern che vediamo frequentemente nei progetti che ereditiamo:

1. Tutto monolitico

Frontend, backend, database, code di lavoro: tutto in un unico processo, tutto sulla stessa macchina. Funziona bene per 100 utenti, esplode a 10.000.

Fix tipico: separare gradualmente, partendo dal frontend, poi le code asincrone, poi eventualmente microservizi mirati.

2. Sessioni in memoria del singolo server

Se l'utente si autentica sul server A, deve rifare login sul server B. Impossibile mettere più server dietro un load balancer.

Fix tipico: spostare le sessioni su storage condiviso.

3. Letture massive senza cache

Ogni pagina genera 50 query database, anche se gli stessi dati sono richiesti da migliaia di utenti. Il database diventa il collo di bottiglia.

Fix tipico: layer di cache aggressiva sulle query a bassa volatilità.

4. File caricati nel filesystem del server

Se l'utente carica file su un server, quei file non sono visibili dagli altri server. Impossibile scalare orizzontalmente.

Fix tipico: spostare i file su storage condiviso (object storage cloud).

Quanto investire in scalabilità per progetto

Tre profili tipici:

Per MVP focalizzato

Investimento minimo: applicare le 6 decisioni base, usare servizi cloud che scalano nativamente. Costo aggiuntivo: trascurabile. Risultato: pronto a crescere senza riscritture quando arriva il traffico.

Per business app standard

Investimento medio: applicare tutte le 6 decisioni, aggiungere caching strategy attiva, configurare auto-scaling. Costo aggiuntivo: 10-15% rispetto a una versione "non scalabile". Risultato: regge fino a decine di migliaia di utenti senza intervento.

Per sistema enterprise

Investimento alto: oltre alle 6 decisioni, architettura distribuita, replica database multi-regione, CDN globale, observability avanzata. Costo aggiuntivo: 25-40%. Risultato: regge milioni di utenti, alta disponibilità, multi-regione.

Conclusione

Scalabilità non è un interruttore da accendere quando serve: è il risultato di decisioni progettuali prese al momento giusto. Le sei decisioni descritte in questa guida sono quasi gratuite all'inizio e molto costose dopo.

L'errore più comune nei progetti che ereditiamo non è "ho scelto male la tecnologia". È "non ho deciso niente all'inizio, ho lasciato che le decisioni si prendessero da sole strada facendo". Quando emergono bottleneck di scaling, scopri che le decisioni implicite erano sbagliate.

La scalabilità si pianifica, non si improvvisa.