Hier, un de nos services a planté pendant 3 heures en pleine journée. La raison ? Un truc tout bête qu'on oublie souvent de surveiller. On avait une API qui tournait nickel en développement. En production, dès qu'on dépassait 80 utilisateurs simultanés : tout partait en vrille. Des timeouts partout, des erreurs 503, le chaos total. Le problème n'était ni le serveur, ni la base de données. C'était le pool de connexions. Voilà ce qui se passait : notre pool PostgreSQL avec 15 connexions (config par défaut jamais modifiée), chaque requête gardait une connexion 300ms, et avec 80 req/s on avait besoin de 24 connexions. Résultat : 9 connexions manquantes, files d'attente explosées, utilisateurs perdus. La solution n'était pas juste d'augmenter le nombre. On a : • Monté le pool à 40 avec timeouts explicites • Activé la détection de fuites de connexions • Ajouté du monitoring temps réel • Optimisé les transactions longues Le truc qui m'a le plus marqué ? Tu peux avoir une base qui encaisse 5000 req/s, mais avec un pool limité à 15, tu plafonneras à 50 req/s. C'est le goulot d'étranglement invisible. Maintenant je vérifie systématiquement : taille du pool adaptée à la charge ? Timeouts configurés ? Monitoring actif ? Un pool de connexions, c'est comme les places de parking d'un centre commercial. Tu peux avoir le plus beau magasin du monde, si les clients ne trouvent pas où se garer, ils vont ailleurs.