Escalabilidad en Strapi: patrones para proyectos que crecen más allá del MVP

Una instalación con SQLite y sin caching funciona bien para desarrollo y MVPs con tráfico bajo. Los primeros síntomas de límite aparecen cuando el volumen de contenido supera los pocos miles de registros, cuando el tráfico de API crece a centenares de requests por minuto, o cuando múltiples procesos necesitan acceder al mismo estado.

SQLite es el primer límite real: solo admite un escritor a la vez y no soporta múltiples instancias del proceso de Strapi accediendo al mismo archivo. Para cualquier entorno que no sea desarrollo local, PostgreSQL es la base de datos correcta.

Con PostgreSQL, el siguiente límite suele ser el pool de conexiones. Si el hosting escala horizontalmente con múltiples instancias de Strapi, cada una abre su propio pool. Sin un proxy como PgBouncer, la base de datos puede saturarse de conexiones inactivas antes de saturarse de carga real.

Los índices son la optimización más impactante. Por defecto, Strapi indexa los campos que usa para relaciones y filtros básicos. Si tus queries usan filtros personalizados frecuentes (por fecha, por estado, por campo de texto), agregar índices en esas columnas puede reducir el tiempo de query de segundos a milisegundos.

El plugin de REST cache para Strapi permite cachear respuestas de la Content API en Redis. Para contenido que cambia poco y se consulta mucho (categorías, navegación, páginas de marketing), el cache elimina la mayoría de las consultas a la base de datos.

La invalidación del cache es el punto crítico. Cuando se actualiza un registro desde el admin de Strapi, el cache se invalida automáticamente para las colecciones configuradas. Si hay lógica de actualización externa (scripts, importadores, webhooks), hay que invalidar el cache manualmente.

Strapi soporta múltiples instancias en paralelo, pero los assets del admin panel deben estar accesibles para todos los procesos. En entornos con múltiples instancias, esos assets deben servirse desde un volumen compartido o desde un CDN, no desde el filesystem local de cada instancia.

Para la mayoría de proyectos que crecen más allá del MVP, la secuencia correcta es: PostgreSQL, luego Redis para cache, luego ajuste de índices, y solo después clustering si el volumen lo justifica. Saltarse pasos anteriores e ir directo al clustering añade complejidad sin resolver el cuello de botella real.