"Incluso si no en los próximos meses" huele a optimización prematura. No hagas eso:
Que no vale la pena. Muchas personas, al realizar un proyecto, creen que su proyecto será el segundo Facebook. Luego lo lanzan, y luego notan que diez visitantes por mes es lo mejor que pueden hacer. Gastar menos dinero y tiempo en la optimización para una mayor escalabilidad y más tiempo pensando en el proyecto en sí ayudaría.
Es como con los cuellos de botella y los perfiles: siempre tiene la impresión de que sabe perfectamente dónde está el cuello de botella y, en la mayoría de los casos, descubre que se equivocó al perfilar. Haz tu solicitud primero. Mira cómo se usa. Perfílalo. Recopilar datos de BI. Reúna métricas de rendimiento. Analízalo. Comprueba si tu análisis fue correcto. Realice las predicciones sobre el futuro, basándose en su análisis, luego optimice para la escalabilidad lo que realmente necesita optimizar.
Por ejemplo, una aplicación web escalable debe poder alojarse en varios servidores. El último proyecto que hice para mi cliente tenía la intención de ser escalable. Había una opción: o gastamos 1,5 meses más para hacer que la aplicación web funcione en varios servidores, o el cliente compra un servidor de alta calidad (solo una máquina) y la aplicación web está alojada solo en esta máquina. Era mucho menos costoso comprar un servidor costoso, contando tanto el costo directo (precio del servidor vs. precio de 1.5 meses de trabajo) como el ahorro a largo plazo (consumo de energía de un servidor de alta calidad vs. consumo de energía de varios -end servidores). Ahora, la aplicación se ejecuta durante unos meses y, según las métricas, si algún día hubiera un problema con la escalabilidad, en primer lugar, se trataría de la base de datos,
Ahora, una aplicación puede ser más o menos escalable en varios puntos:
Base de datos: según mi experiencia personal, la mayoría de los problemas relacionados con la escalabilidad provienen de la base de datos. Con suerte, hay muchas maneras de hacer que la base de datos sea escalable para cada motor de base de datos de grado industrial, e incluso antes de eso, hay muchas maneras de mejorar la estructura de la base de datos y optimizar las consultas . El almacenamiento en caché también ayuda.
Red: el ancho de banda puede ser un problema real en algunas configuraciones, y a veces no puede hacer nada al respecto sin hacer gastos que no puede pagar. Para evitar ser bloqueado en este nivel, puede optimizar el diseño visual del sitio web para tener menos imágenes o mejores imágenes comprimidas , optimizar el diseño de la página, reducir las solicitudes HTTP (a través de sprites CSS ), reducir la cantidad de HTML código enviado (a través de AJAX ), etc. La compresión HTTP es imprescindible. El almacenamiento en caché del navegador también, pero sus métricas pueden mostrar que muchos clientes tienen un caché vacío.
Uso de CPU y memoria: portar una aplicación para ser alojado por varios servidores también puede ser doloroso, tanto a nivel de infraestructura (hardware) como a nivel de aplicación (software). Para evitar esto, use un almacenamiento en caché extenso y perfile la aplicación, eliminando progresivamente los cuellos de botella .