Che cos'è il connection pooling serverless?

Il connection pooling serverless è una tecnica che condivide poche connessioni reali al database tra molte istanze di funzioni di breve durata. Esiste perché due modelli di scalabilità non vanno d’accordo: il calcolo serverless risponde al carico moltiplicando le istanze, mentre un database tratta ogni connessione come una risorsa costosa, sostenuta da memoria e con un tetto rigido. Messi insieme in modo ingenuo, un picco di traffico modesto diventa un’interruzione too many connections.

Punti chiave

Il guasto, osservato dal database

-- Che cosa vede il database durante un picco di traffico serverless:
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
--  active               |   14
--  idle                 |  483     ← parcheggiate dalle istanze di funzione calde
SHOW max_connections;    --  100    ← il tetto che hanno già sfondato

-- Ogni connessione è un processo reale che occupa memoria reale –
-- ecco perché il tetto esiste e perché alzarlo non è la soluzione.

La forma del problema: ogni istanza di funzione apre la propria connessione, la tiene durante i tempi morti tra un’invocazione e l’altra, e il numero di istanze lo decide il traffico, non chi sviluppa. Il riuso avviene solo dentro un’istanza calda – mai tra istanze diverse – quindi una concorrenza di 300 significa 300 pool a connessione singola. Alzare max_connections compra margine al prezzo di memoria reale e perde contro il picco successivo, più grande.

Su un backend gestito, il codice applicativo esce del tutto da questa lotta – le chiamate SDK sono richieste HTTPS stateless, e nessun client detiene mai una connessione al database:

// JavaScript / Node.js — Back4app JS SDK
// Inside a serverless function: no driver, no pool, no connection to leak.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com';

export async function handler(event) {
  const query = new Parse.Query('Order');
  query.equalTo('status', 'pending');
  query.limit(20);
  const orders = await query.find();  // request returns; nothing stays open
  return orders.map((o) => o.id);
}
// 1,000 concurrent invocations = 1,000 HTTP requests,
// not 1,000 database connections.

// Flutter / Dart — Back4app Flutter SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
await Parse().initialize(
  'APP_ID',
  'https://parseapi.back4app.com',
  clientKey: 'CLIENT_KEY',
);

Future<List<String>> pendingOrderIds() async {
  final query = QueryBuilder<ParseObject>(ParseObject('Order'))
    ..whereEqualTo('status', 'pending')
    ..setLimit(20);
  final response = await query.query(); // request returns; nothing stays open
  return response.results!
      .map((o) => (o as ParseObject).objectId!)
      .toList();
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// iOS / Swift — Back4app Swift SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
ParseSwift.initialize(
  applicationId: "APP_ID",
  clientKey: "CLIENT_KEY",
  serverURL: URL(string: "https://parseapi.back4app.com")!
)

let query = Order.query("status" == "pending")
  .limit(20)
query.find { result in
  if case .success(let orders) = result {
    render(orders)                 // request returned; nothing stays open
  }
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// Android / Kotlin — Back4app Android SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId("APP_ID")
        .clientKey("CLIENT_KEY")
        .server("https://parseapi.back4app.com")
        .build()
)

val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "pending")
query.limit = 20
query.findInBackground { orders, e ->
    if (e == null) render(orders)  // request returned; nothing stays open
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

Come un pooler assorbe il fan-out

Un pooler come PgBouncer accetta connessioni client a migliaia – ciascuna economica dal suo lato – e presta connessioni server reali da un piccolo pool solo quando arriva del lavoro. Il database vede venti connessioni tranquille; cinquecento funzioni credono di averne una ciascuna. Quando la domanda supera il pool, i client attendono millisecondi in coda invece di ricevere errori – un fallimento secco si converte in una latenza modesta.

Il dimensionamento del pool è il punto in cui l’intuizione fallisce di più. Il parallelismo utile di un database è limitato da core e disco – il throughput di solito raggiunge il picco con un pool di poche decine di connessioni, intorno al numero di core per due, e poi cala man mano che altre connessioni aggiungono contesa. L’aritmetica del pooler funziona perché le richieste serverless sono brevi: una connessione che serve una transazione da 8 ms può servirne ben più di cento al secondo, quindi venti connessioni reali assorbono comodamente migliaia di invocazioni di funzioni. Il pool non è una cache di comodo; è un collo di bottiglia deliberato, piazzato dove mettersi in coda costa poco.

La manopola cruciale è quanto dura il prestito.

Pooling per transazione vs. pooling per sessione

La modalità transazione è ciò che rende praticabili i carichi serverless – una funzione che esegue una transazione da 8 ms non dovrebbe possedere una connessione per i minuti della sua vita a caldo – ma non è gratis: tutto ciò che presume che “la propria connessione” persista tra un’istruzione e l’altra diventa un bug subdolo. Il consiglio consolidato: pooling per transazione per il traffico di richieste, connessione diretta o con pool di sessione per le migrazioni e per tutto ciò che ha stato.

Casi d’uso tipici

• Funzioni serverless ed edge che interrogano SQL. Il caso canonico – numeri di istanze a picchi contro un budget di connessioni fisso.
• Molti piccoli servizi, un solo database. Venti servizi × pool predefiniti da dieci connessioni = 200 connessioni che nessuno aveva pianificato; un pooler condiviso ristabilisce un’aritmetica sana.
• Piattaforme multi-tenant. I carichi per tenant moltiplicano la domanda di connessioni; il pooling permette di far rispettare il budget del database condiviso.
• Raffiche di traffico su database modesti. I picchi del giorno del lancio si mettono in coda al pooler per millisecondi invece di generare errori nel database.
• Proteggere il primario durante gli incidenti. Un pool di dimensione fissa è una paratia: i client fuori controllo esauriscono la coda del pooler, non la memoria del database.

Conviene gestire un pooler in proprio? Matrice decisionale

L’asimmetria, detta onestamente: un pooler risolve l’esaurimento delle connessioni; un backend gestito lo dissolve. Quando i client parlano HTTPS con API generate automaticamente, il fan-out non raggiunge mai il livello database – il pooling avviene comunque, ma come infrastruttura collaudata di qualcun altro anziché come componente da gestire in proprio.

Limiti e trade-off

• Un pooler è un componente. Richiede deployment, monitoring, failover e aggiornamenti – si è scambiato un problema di risorse con un problema operativo, a un cambio favorevole ma non nullo.
• La modalità transazione cambia la semantica. Prepared statement, variabili di sessione e advisory lock smettono di comportarsi come documentato; i fallimenti sono intermittenti e dipendono dal carico – il tipo peggiore.
• Un salto in più costa latenza. Di norma sotto il millisecondo dentro la rete, ma sta sul percorso di ogni query.
• Il pooler può essere il collo di bottiglia. Un pooler a thread singolo sotto un picco violento accumula una coda profonda; il tetto si è spostato, non è sparito.
• Il pooling non corregge le query lente. Raziona le connessioni; una query che tiene il prestito per secondi lascia il pool a secco. Query veloci – e gli indici dietro di esse – restano la vera leva di capacità.

Il connection pooling 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. La sua architettura risponde alla domanda sul pooling in modo strutturale: le app client e le funzioni Cloud Code emettono richieste HTTPS stateless, ed è il livello server della piattaforma – non il codice applicativo – a mantenere pool di connessioni di lunga durata e dimensionati correttamente verso il database gestito. Il fan-out delle istanze sul lato di calcolo non si traduce mai in fan-out di connessioni sul lato database, che è esattamente la proprietà che tutto questo articolo esiste per costruire.