Tu app funcionó bien con tu equipo y con los primeros usuarios. Un día llega una campaña, entran veinte personas a la vez y se cae. Casi siempre hay una explicación, y se puede corregir.
Lo que suele fallar
- Límites de conexión a la base de datos. Cada usuario abre conexiones y se agotan. Hay que controlar cuántas se abren y cerrar las que no se usan.
- Trabajo pesado en la misma petición. Si generar un reporte o enviar un correo bloquea al usuario, pocas personas a la vez saturan el servidor.
- Un solo proceso atendiendo todo. Sin varios procesos o instancias, una petición lenta frena a las demás.
- Planes gratuitos o mínimos. Tienen límites de CPU, memoria o peticiones por minuto, y algunos servicios se “duermen” cuando no se usan.
- Servicios externos sin control. Llamadas a APIs de terceros sin tiempo máximo, sin reintentos y sin colas.
- Estado guardado en memoria. Sesiones o datos temporales que se pierden o se desincronizan cuando hay más de una instancia.
Cómo comprobarlo antes de que pase
Una prueba de carga simula usuarios reales sobre tu app de forma controlada. Con una herramienta como k6 puedes simular decenas o cientos de usuarios y ver en qué punto aparecen errores o tiempos altos.
Qué se corrige, en orden
- Encontrar el cuello de botella con la prueba de carga.
- Pasar el trabajo pesado a colas.
- Agregar caché y ajustar las consultas.
- Configurar el número de procesos y de conexiones.
- Subir el tamaño del servidor solo cuando lo anterior ya está resuelto.
Deja la prueba de carga lista para repetirla cada vez que lances algo grande. Así los problemas los encuentras tú y no tus clientes.
Si tu app se cae al crecer, mira cómo llevo proyectos a producción.