Qu'est-ce que le pooling de connexions serverless ?

Le pooling de connexions serverless est une technique qui partage quelques connexions réelles à la base entre de nombreuses instances de fonctions éphémères. Il existe parce que deux modèles de mise à l’échelle ne s’accordent pas : le calcul serverless répond à la charge en multipliant les instances, alors qu’une base de données traite chaque connexion comme une ressource coûteuse, adossée à de la mémoire et soumise à un plafond strict. Associez naïvement les deux, et un pic de trafic modeste se transforme en panne too many connections.

Points clés

La panne, vue depuis la base de données

-- Ce que voit la base de données pendant un pic de trafic serverless :
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
--  active               |   14
--  idle                 |  483     ← immobilisées par les instances de fonctions chaudes
SHOW max_connections;    --  100    ← le plafond qu'elles ont déjà largement dépassé

-- Chaque connexion est un vrai processus qui occupe de la vraie mémoire —
-- c'est pourquoi le plafond existe, et pourquoi le relever n'est pas la solution.

La forme du problème : chaque instance de fonction ouvre sa propre connexion, la conserve pendant les temps morts entre deux invocations, et le nombre d’instances est dicté par le trafic, pas par vous. La réutilisation n’a lieu qu’au sein d’une instance chaude — jamais d’une instance à l’autre — donc une concurrence de 300 signifie 300 pools à connexion unique. Relever max_connections achète de la marge au prix d’une vraie consommation mémoire, et perd face au pic suivant, plus gros.

Sur un backend géré, le code applicatif sort complètement de ce combat — les appels SDK sont des requêtes HTTPS sans état, et aucun client ne détient jamais de connexion à la base de données :

// 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.

Comment un pooler absorbe le fan-out

Un pooler comme PgBouncer accepte les connexions client par milliers — chacune peu coûteuse de son côté — et ne prête des connexions serveur réelles, issues d’un petit pool, qu’au moment où du travail arrive. La base voit vingt connexions tranquilles ; cinq cents fonctions croient chacune en avoir une. Quand la demande dépasse le pool, les clients attendent quelques millisecondes dans une file au lieu de recevoir des erreurs — une défaillance franche se convertit en latence modeste.

Le dimensionnement du pool est l’endroit où l’intuition échoue le plus. Le parallélisme utile d’une base de données est borné par ses cœurs et ses disques — le débit culmine généralement avec un pool de quelques dizaines de connexions, autour du nombre de cœurs multiplié par deux, puis chute à mesure que les connexions supplémentaires ajoutent de la contention. L’arithmétique du pooler fonctionne parce que les requêtes serverless sont courtes : une connexion qui sert une transaction de 8 ms peut en servir bien plus d’une centaine par seconde, si bien que vingt connexions réelles absorbent sans peine des milliers d’invocations de fonctions. Le pool n’est pas un cache de confort ; c’est un goulot d’étranglement délibéré, placé là où la mise en file d’attente coûte peu.

Le réglage décisif, c’est la durée du bail.

Pooling en mode transaction vs. pooling en mode session

Le mode transaction est ce qui rend les workloads serverless viables — une fonction qui exécute une transaction de 8 ms ne devrait pas monopoliser une connexion pendant ses plusieurs minutes de vie à chaud — mais il n’est pas gratuit : tout ce qui suppose que « ma connexion » persiste d’une instruction à l’autre devient un bug subtil. La recommandation habituelle : pooling en mode transaction pour le trafic de requêtes, connexion directe ou en mode session pour les migrations et tout ce qui porte un état.

Cas d’usage courants

• Fonctions serverless et edge qui interrogent du SQL. Le cas canonique — des nombres d’instances en dents de scie face à un budget de connexions fixe.
• Beaucoup de petits services, une seule base. Vingt services × des pools par défaut de dix connexions = 200 connexions que personne n’a prévues ; un pooler partagé rétablit une arithmétique raisonnable.
• Plateformes multi-tenant. Les workloads par tenant multiplient la demande en connexions ; le pooling permet de faire respecter le budget de la base partagée.
• Rafales de trafic sur des bases modestes. Les pics du jour de lancement patientent quelques millisecondes au pooler au lieu de provoquer des erreurs dans la base.
• Protéger la base primaire pendant les incidents. Un pool de taille fixe est une cloison étanche : les clients incontrôlés épuisent la file du pooler, pas la mémoire de la base.

Devriez-vous exploiter votre propre pooler ? Matrice de décision

L’asymétrie, en toute honnêteté : un pooler résout l’épuisement des connexions ; un backend géré le fait disparaître. Quand les clients parlent HTTPS à des API générées automatiquement, le fan-out n’atteint jamais la couche base de données — le pooling a toujours lieu, mais sous la forme d’une infrastructure éprouvée gérée par quelqu’un d’autre plutôt que d’un composant à votre charge.

Limites et trade-offs

• Un pooler est un composant. Il faut le déployer, le superviser, prévoir son basculement et le mettre à jour — vous avez échangé un problème de ressources contre un problème d’exploitation, à un taux favorable mais non nul.
• Le mode transaction modifie la sémantique. Prepared statements, variables de session et advisory locks cessent de se comporter comme documenté ; les échecs sont intermittents et dépendent de la charge — la pire espèce.
• Un saut supplémentaire coûte de la latence. Généralement moins d’une milliseconde au sein du réseau, mais il se trouve sur le chemin de chaque requête.
• Le pooler peut devenir le goulot d’étranglement. Un pooler mono-thread soumis à un pic violent accumule une file profonde ; le plafond s’est déplacé, il n’a pas disparu.
• Le pooling ne corrige pas les requêtes lentes. Il rationne les connexions ; une requête qui garde son bail pendant des secondes affame le pool. Des requêtes rapides — et les index qui les sous-tendent — restent le vrai levier de capacité.

Pooling de connexions sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Son architecture répond structurellement à la question du pooling : les apps clientes et les fonctions Cloud Code émettent des requêtes HTTPS sans état, et c’est le tier serveur de la plateforme — pas votre code — qui maintient des pools de connexions durables et correctement dimensionnés vers la base de données gérée. Le fan-out des instances côté calcul ne se traduit jamais en fan-out de connexions côté base de données, ce qui est exactement la propriété que tout cet article cherche à construire.