---
term: 'Scalabilità dei backend applicativi moderni'
seoTitle: 'Scalabilità dei backend moderni: strategie e trade-off'
headline: 'Come si scala un backend applicativo moderno?'
slug: scalabilita-del-backend
category: cloud-architecture
shortDefinition: 'Scalare un backend applicativo moderno è un processo di aggiunta di capacità – calcolo, database, distribuzione – perché il traffico in crescita resti veloce.'
relatedTerms:
  - multi-region-database-replication
  - serverless-connection-pooling
  - cdn-content-delivery-network
  - serverless-architecture
  - database-index
contrastsWith:
  - serverless-architecture
faq:
  - question: 'Che cosa significa scalare un backend?'
    answer: 'Aggiungere capacità perché il backend mantenga tempi di risposta e affidabilità mentre traffico e dati crescono: più calcolo per il livello applicativo, più throughput in lettura o scrittura per il database, e una distribuzione più veloce per i contenuti statici e in cache. La scalabilità è una proprietà che si progetta (statelessness, indici, paginazione) prima di essere una risorsa che si compra.'
  - question: 'Qual è la differenza tra scalabilità verticale e orizzontale?'
    answer: 'La scalabilità verticale potenzia una sola macchina: più CPU, più RAM, dischi più veloci. È semplice e conserva la semantica a nodo singolo, ma incontra un soffitto hardware e resta un single point of failure. La scalabilità orizzontale aggiunge macchine dietro un load balancer, il che toglie il soffitto e aggiunge tolleranza ai guasti, ma richiede servizi stateless e una strategia per il database.'
  - question: 'Perché i servizi di backend devono essere stateless per scalare in orizzontale?'
    answer: 'Perché un load balancer deve essere libero di mandare qualunque richiesta a qualunque istanza. Se lo stato di sessione vive nella memoria di un server, le richieste restano inchiodate a quello, le istanze smettono di essere intercambiabili e aggiungere macchine smette di aggiungere capacità. I servizi stateless tengono lo stato nel database o in una cache condivisa, così le istanze si possono aggiungere, sostituire o spegnere a piacere.'
  - question: 'Come si scala il livello del database?'
    answer: 'In ordine crescente: aggiungere gli indici giusti e correggere le query costose; mettere in cache le letture calde; usare il pooling delle connessioni perché un calcolo a picchi non esaurisca il server; aggiungere repliche di lettura per distribuire il carico in lettura; e solo a quel punto valutare lo sharding o la replica multi-regione, che comprano margine a un costo reale in complessità e compromessi sulla coerenza.'
  - question: 'Quando conviene iniziare a scalare un backend?'
    answer: 'Quando lo dicono le misure – latenza p95 che sale, connessioni esaurite, ritardo di replica, code che si accumulano – non quando i diagrammi di architettura fanno bella figura. Scalare troppo presto compra complessità prima di comprare capacità. Le abitudini che non costano nulla (statelessness, indici, paginazione, cache) valgono dal primo giorno; il macchinario (repliche, shard, regioni) aspetta le prove.'
  - question: 'Un BaaS scala automaticamente?'
    answer: 'In gran parte sì, per la metà infrastrutturale: le piattaforme gestite fanno girare il livello applicativo in modo stateless dietro il bilanciamento del carico, scalano il calcolo in automatico, mettono in pool le connessioni al database e servono i file attraverso una CDN. Quello che nessuna piattaforma automatizza è la metà ingegneristica – modellazione dei dati, indici, forma delle query e paginazione – che decide ancora se la capacità aggiunta si traduce in traffico servito.'
  - question: 'Che ruolo ha la cache nella scalabilità del backend?'
    answer: 'È la leva con il rapporto migliore dopo l''indicizzazione: un hit in cache costa microsecondi e zero lavoro al database, quindi ogni punto percentuale di hit rate toglie carico reale. L''ordine conta: CDN per gli asset statici, cache applicativa o di query per le letture calde, cache dei buffer del database sotto. L''avvertenza classica è l''invalidazione, perché una cache stantia baratta correttezza per velocità.'
  - question: 'La scalabilità è un motivo per lasciare un BaaS?'
    answer: 'Raramente ai livelli di traffico che la maggior parte dei prodotti raggiunge: le piattaforme gestite reggono carichi notevoli, e le leve che contano di più (indici, forma delle query, cache) funzionano allo stesso modo anche lì. Il punto di sorpasso onesto è il carico estremo e costante, dove i prezzi a consumo si rovesciano contro l''infrastruttura fissa, oppure topologie su misura che una piattaforma non sa esprimere: conviene misurare prima di dare per scontata una delle due ipotesi.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Scalability — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Scalability'
  - name: 'The Twelve-Factor App: Processes (statelessness)'
    url: 'https://12factor.net/processes'
  - name: 'Horizontal vs. vertical scaling — MongoDB'
    url: 'https://www.mongodb.com/resources/basics/horizontal-vs-vertical-scaling'
  - name: 'PostgreSQL high availability & replication documentation'
    url: 'https://www.postgresql.org/docs/current/high-availability.html'
cta:
  title: 'Scalare senza il progetto di scalabilità'
  text: 'Back4app fa girare il backend stateless, bilanciato e con scalabilità automatica – con connessioni al database in pool, indici sotto controllo diretto e una CDN davanti ai file. Le leve che contano restano in mano a chi sviluppa; il macchinario lo assorbe la piattaforma.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-30'
translationKey: scaling-application-backends
---

**Scalare un backend applicativo moderno è un processo di aggiunta di capacità – calcolo, database, distribuzione – perché il traffico in crescita resti veloce.** La parte che le pubblicità dell'hardware saltano: la scalabilità è una *proprietà* prima di essere un acquisto. Un backend costruito su servizi stateless, query indicizzate e letture paginate scala aggiungendo macchine; un backend senza quelle proprietà trasforma ogni macchina aggiunta in pubblico di uno stesso collo di bottiglia. Questa pagina è il quadro decisionale – le leve, il loro ordine e quando ciascuna è prematura; per la costruzione passo per passo c'è la [guida completa a come costruire un backend scalabile](https://blog.back4app.com/how-to-build-a-scalable-backend/).

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è la scalabilità | Capacità aggiunta su tre livelli: calcolo, database, distribuzione |
| Il prerequisito | Statelessness: qualunque istanza deve poter servire qualunque richiesta |
| Le due direzioni | Verticale (macchina più grande) vs. orizzontale (più macchine) |
| L'ordine delle leve | Indice → cache → pool → replica → sharding/multi-regione |
| La vittoria più economica | Le richieste che non si fanno mai: letture selettive, paginate, in cache |
| Che cosa assorbe un BaaS | Il macchinario (bilanciamento, scalabilità automatica, pooling, CDN), non il modello dei dati |

## La scalabilità più economica sta nella query

Prima di qualsiasi modifica all'infrastruttura, la prima leva è la richiesta stessa: campi selettivi, un filtro indicizzato, una pagina invece di una scansione completa, un batch invece di N giri di rete:

**JavaScript:**

```javascript
// The cheapest scaling is the request you never make.
// A read path that stays fast at 10x the data: selective, indexed, paginated.
const query = new Parse.Query('Order');
query.equalTo('status', 'open');       // hits the status index
query.select('total', 'createdAt');    // only the fields the list renders
query.descending('createdAt');         // matches the index order
query.limit(50);                       // a page, never "fetch all"
const page = await query.find();

// Writes that batch: one round trip for the whole cart, not N.
const items = cart.map((i) => new Parse.Object('LineItem', i));
await Parse.Object.saveAll(items);
```

**Flutter:**

```dart
// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'open')          // hits the status index
  ..keysToReturn(['total', 'createdAt'])    // only what the list renders
  ..orderByDescending('createdAt')          // matches the index order
  ..setLimit(50);                           // a page, never "fetch all"
final page = await query.query();

// Writes that batch: one round trip for the whole cart, not N.
final items = cart.map((i) => ParseObject('LineItem')..set('sku', i.sku)).toList();
await ParseObject('LineItem').saveAll(items);
```

**Swift:**

```swift
// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
var query = Order.query("status" == "open")   // hits the status index
query.select = ["total", "createdAt"]          // only what the list renders
query.order = [.descending("createdAt")]       // matches the index order
query.limit = 50                               // a page, never "fetch all"
let page = try await query.find()

// Writes that batch: one round trip for the whole cart, not N.
let items = cart.map { LineItem(sku: $0.sku, qty: $0.qty) }
try await LineItem.saveAll(items)
```

**Kotlin:**

```kotlin
// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
val query = ParseQuery.getQuery<ParseObject>("Order")
    .whereEqualTo("status", "open")            // hits the status index
    .selectKeys(listOf("total", "createdAt"))  // only what the list renders
    .orderByDescending("createdAt")            // matches the index order
    .setLimit(50)                              // a page, never "fetch all"
val page = query.find()

// Writes that batch: one round trip for the whole cart, not N.
val items = cart.map { ParseObject("LineItem").apply { put("sku", it.sku) } }
ParseObject.saveAllInBackground(items)
```

Un backend che lo fa ovunque spesso rimanda la scalabilità "vera" di un ordine di grandezza – e quando la scalabilità arriva davvero, sono queste abitudini a far contare la capacità aggiunta.

## Scalabilità verticale vs. orizzontale

| Dimensione | Verticale (scale up) | Orizzontale (scale out) |
| --- | --- | --- |
| Meccanismo | Macchina più grande: CPU, RAM, dischi veloci | Più macchine dietro un load balancer |
| Soffitto | Netto: la macchina più grande acquistabile | Di fatto assente per i livelli stateless |
| Tolleranza ai guasti | Nessuna in più: resta una sola scatola | Le istanze cadono senza far cadere il servizio |
| Prerequisiti | Nessuno: il codice gira invariato | Servizi stateless; sessioni esternalizzate |
| Adatta al database | Naturale: conserva la semantica a nodo singolo | Difficile: servono repliche, poi sharding |
| Curva di costo | Si impenna bruscamente in alto | Quasi lineare, più l'onere di coordinamento |
| Prima mossa giusta per | Database, margine rapido | Livelli applicativi, crescita costante |

La sintesi pratica a cui approda la maggior parte dei sistemi in produzione: **scalare in orizzontale il livello applicativo stateless e in verticale, prima, il database** – repliche e shard solo quando una macchina di database più grande smette di bastare.

## La scala della scalabilità

```mermaid
flowchart LR
  accTitle: La scala della scalabilità del backend
  accDescr: La scalabilità procede in ordine di complessità crescente. Prima si rendono i servizi stateless dietro un load balancer. Poi si riduce il lavoro per richiesta con indici, paginazione e cache più una CDN. Poi si protegge e si estende il database con il pooling delle connessioni e le repliche di lettura. Solo alla fine si ricorre allo sharding o alla replica tra più regioni.
  A["Livello stateless<br/>calcolo bilanciato"] --> B["Meno lavoro per richiesta<br/>indici · paginazione · cache · CDN"]
  B --> C["Margine sul database<br/>pooling · repliche di lettura"]
  C --> D["Ultime risorse<br/>sharding · multi-regione"]
```

Ogni gradino compra capacità a un prezzo crescente in complessità. La [statelessness](https://12factor.net/processes) è il biglietto d'ingresso: un load balancer può aiutare solo se qualunque istanza può servire qualunque richiesta. Gli [indici](/glossary/it/indice-del-database/) e la [disciplina sui payload](/glossary/api-payload-optimization/) riducono il lavoro che ogni richiesta costa. Una [CDN](/glossary/cdn-content-delivery-network/) toglie del tutto il traffico statico dal backend. Il [pooling delle connessioni](/glossary/serverless-connection-pooling/) impedisce al calcolo elastico di strozzare il database, e le repliche di lettura distribuiscono il carico in lettura. [Sharding e replica multi-regione](/glossary/multi-region-database-replication/) stanno per scelta in fondo: risolvono problemi reali introducendo compromessi sulla coerenza che ogni gradino precedente evita.

## Quale leva di scalabilità tirare per prima?

| Sintomo | Prima leva | Non ancora |
| --- | --- | --- |
| Endpoint di elenco/ricerca lenti | Indicizzare il filtro e paginare | Più server |
| p95 alta, CPU bassa | Mettere in cache le letture calde; cercare query N+1 | Database più grande |
| Errori "too many connections" | [Pooling delle connessioni](/glossary/serverless-connection-pooling/) | Sharding |
| Carico in lettura che sale | Repliche di lettura | Multi-regione |
| Utenti lontani, asset lenti | [CDN](/glossary/cdn-content-delivery-network/) per file e statici | Replica tra regioni |
| Throughput in scrittura al muro | Scritture in batch, [code](/glossary/it/job-in-background/) | Sharding, e forse |

Lo schema è questo: **la maggior parte dei momenti "dobbiamo scalare" dista una query indicizzata, una cache o un pool dalla soluzione.** Il macchinario costoso si guadagna la propria complessità solo dopo che le leve economiche sono esaurite – e il monitoring (latenza p95, numero di connessioni, ritardo di replica) è ciò che dice in quale riga ci si trova.

## Che cosa assorbe un backend gestito

Le metà [serverless](/glossary/it/architettura-serverless/) e [NoOps](/glossary/it/sviluppo-no-ops/) di questo problema sono esattamente ciò che una piattaforma gestita impacchetta: il livello applicativo gira stateless e bilanciato per costruzione, il calcolo scala in automatico con il traffico, le connessioni al database arrivano già in pool e i file viaggiano attraverso una CDN senza cablaggi. Questo riduce i gradini infrastrutturali della scala a impostazioni predefinite della piattaforma – e quello che resta da fare è la metà ingegneristica: [modellazione dei dati](/glossary/it/modellazione-dei-dati/), indici, [forma delle query](/glossary/it/query-sul-database/) e paginazione. Nessuna piattaforma può rendere veloce la scansione completa di una tabella non indicizzata; ogni piattaforma seria fa in modo che sia l'unico tipo di lentezza che si possa ancora costruire.

## Casi d'uso tipici

- **Il picco del lancio** – un prodotto diventa virale per un fine settimana; il calcolo stateless con scalabilità automatica lo assorbe, e il database sopravvive perché le letture erano paginate e in cache.
- **Crescita costante** – gli utenti attivi mensili si moltiplicano; la scala si sale gradino per gradino quando le misure lo richiedono, non per congettura.
- **Prodotti con molte letture** – contenuti, cataloghi, dashboard; CDN, cache e repliche reggono rapporti di lettura di 100:1 senza toccare i percorsi di scrittura.
- **Carichi a raffica** – campagne, lanci a tempo, picchi stagionali; il calcolo elastico più il [lavoro in background accodato](/glossary/it/job-in-background/) appiattiscono il picco.
- **Pubblico globale** – utenti sensibili alla latenza e lontani dall'origine; la distribuzione scala prima con una [CDN](/glossary/cdn-content-delivery-network/), e solo se la località dei dati lo impone davvero con i [dati multi-regione](/glossary/multi-region-database-replication/).

## Conviene già scalare? Matrice decisionale

| Situazione | Orientamento |
| --- | --- |
| Latenza p95 e tassi di errore sono piatti | No – aggiungere monitoring, non macchinario |
| Un solo endpoint è lento | Correggere query e indice: è ottimizzazione, non scalabilità |
| CPU al massimo sul livello app, database sano | Scalare il calcolo in orizzontale: il gradino facile |
| Connessioni al database esaurite | Pooling prima di qualsiasi cosa più grande |
| Le letture dominano e continuano a crescere | Cache, poi repliche di lettura |
| Le scritture saturano un primario già ottimizzato | Ora la conversazione difficile: sharding / rimodellazione |
| Si progetta per un carico futuro immaginato | Adottare le abitudini gratuite; rimandare il macchinario |

## Limiti e trade-off

- **La moneta è la complessità.** Ogni gradino della scala aggiunge parti in movimento – bilanciatori, repliche, invalidazione, ritardo – che vanno gestite e debuggate. Conviene comprare capacità con complessità solo quando le misure lo impongono.
- **Le cache barattano freschezza per velocità.** L'invalidazione è notoriamente difficile; ogni cache aggiunta è un contratto di coerenza che da quel momento si deve mantenere.
- **La replica introduce ritardo.** Le repliche di lettura servono dati leggermente stantii; il codice che legge subito dopo aver scritto deve saperlo. Il multi-regione fa lo stesso baratto su scala continentale.
- **Lo sharding è una porta a senso unico.** Query e transazioni tra shard diventano più difficili per sempre: prima vanno esauriti indici, cache e repliche.
- **La scalabilità amplifica il modello di dati che si ha.** Gli schemi buoni scalano con grazia; quelli cattivi scalano le proprie patologie. Il lavoro poco glamour – [modellazione](/glossary/it/modellazione-dei-dati/), indici, forma delle query – decide quanto vale il macchinario costoso.

## Scalabilità dei backend su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il macchinario della scala della scalabilità è la postura predefinita della piattaforma: calcolo stateless, bilanciato e con scalabilità automatica; connessioni al database in pool; file dietro una CDN – mentre le leve che questo articolo insiste a considerare decisive restano in mano a chi sviluppa, con [gestione visuale degli indici](/glossary/it/indice-del-database/), SDK pensati sulla forma delle query che rendono naturali le letture selettive e paginate, e [job in background](/glossary/it/job-in-background/) per il lavoro che non deve bloccare una richiesta. A chi sviluppa restano i gradini ingegneristici; quelli infrastrutturali la piattaforma li ha già saliti.