Tu API tiene muchas lecturas y la base de datos está al noventa por ciento de CPU. ¿Cómo la escalarías?

Averigua qué está quemando la CPU antes de comprar nada. Si un puñado de consultas domina, indéxalas o reescríbelas. Si es volumen de lectura real, añade réplicas y enruta el tráfico de solo lectura ahí, y luego cachea los resultados más calientes con un tiempo de vida corto. Quitar patrones N más uno y limitar el tamaño de página suele comprar más que el hardware. Escala la instancia hacia arriba para ganar tiempo, y luego arregla bien el patrón de consultas.

Antes de añadir nada quiero saber qué está haciendo la CPU, así que saco las consultas principales por tiempo total de pg_stat_statements o su equivalente. Por mi experiencia un número pequeño de consultas hace casi todo el daño, y a menudo una de ellas es un N más uno de un ORM que fue a peor según creció un cliente. Arreglar eso es gratis comparado con mantener réplicas. Si el perfil de verdad dice que es volumen de lectura repartido, entonces las réplicas tienen sentido y enruto ahí los endpoints de solo lectura. La pega es el retraso de replicación, así que cualquier cosa que lea justo después de escribir va al primario, o el usuario ve su propia actualización desaparecer. Después de eso cacheo los pocos endpoints más calientes con un tiempo de vida corto. En paralelo escalaría la instancia verticalmente, porque es un cambio de quince minutos que compra margen para hacer el resto bien. Intento ser explícito con el equipo en que escalar hacia arriba es un cronómetro, no un arreglo.