Votre API est très sollicitée en lecture et la base est à quatre-vingt-dix pour cent de CPU. Comment la feriez-vous monter en charge ?

Cherchez ce qui brûle le CPU avant d'acheter quoi que ce soit. Si une poignée de requêtes domine, indexez-les ou réécrivez-les. Si c'est un vrai volume de lecture, ajoutez des réplicas et routez-y le trafic en lecture seule, puis mettez en cache les résultats les plus demandés avec une durée de vie courte. Supprimer les motifs N plus un et plafonner les tailles de page rapporte souvent plus que du matériel. Augmentez la taille de l'instance pour gagner du temps, puis corrigez proprement le motif de requêtes.

Avant d'ajouter quoi que ce soit, je veux savoir ce que fait le CPU, donc je sors les requêtes les plus consommatrices en temps total depuis pg_stat_statements ou l'équivalent. D'expérience, un petit nombre de requêtes fait l'essentiel des dégâts, et souvent l'une d'elles est un N plus un venu d'un ORM qui a empiré à mesure qu'un client grossissait. Corriger ça est gratuit comparé à faire tourner des réplicas. Si le profil dit vraiment que c'est un volume de lecture uniforme, alors les réplicas ont du sens et j'y route les endpoints en lecture seule. Le piège, c'est le retard de réplication, donc tout ce qui lit juste après une écriture va sur le primaire, sinon un utilisateur voit sa propre mise à jour disparaître. Ensuite je mets en cache les quelques endpoints les plus demandés avec une durée de vie courte. En parallèle, j'augmenterais la taille de l'instance verticalement, parce que c'est un changement de quinze minutes qui achète de la marge pour faire le reste correctement. J'essaie d'être explicite avec l'équipe : monter en taille est un chronomètre, pas un correctif.