La latencia medida en una pantalla vacía miente. Corres la suite de integración, ves respuestas de 80 ms y publicas. Los usuarios reales golpean la API con cientos de conexiones simultáneas, caché fría después del deploy y un pool de base de datos más pequeño que el tráfico. El load testing corre carga parecida a producción en staging y convierte la latencia en un número que el equipo defiende. El k6, de Grafana, escribe el escenario en JavaScript y hace fallar el build cuando el número cruza la línea acordada.

Un escenario que refleja el tráfico

Los estados de rampa reemplazan un pico instantáneo: 2 minutos subiendo a 50 usuarios virtuales, 5 minutos en meseta, 2 minutos bajando. El think time entre pasos esparce las llamadas como la gente lee pantallas. Los datos de carga vienen de un generador apuntando a staging con una distribución cercana a producción, donde una porción pequeña de búsquedas carga la mayor parte del tráfico. Un escenario con números redondos y distribución uniforme produce una latencia bonita que producción no entrega.

Umbrales que hacen fallar el build

Un umbral convierte la expectativa en regla: http_req_duration: p(95)<400 y http_req_failed: rate<0.01. k6 falla la ejecución cuando los viola; el CI falla junto. Los checks validan el contrato por respuesta, con status y schema del payload. El Google SRE Book (O'Reilly, 2016) trata la latencia y el error como SLI; el umbral de k6 es ese SLI automatizado antes de que exista un SLA firmado.

k6 en el pipeline

Un job de GitHub Actions instala k6, corre el script y publica el resultado como artifact. Un escenario corto de regresión, de 2 minutos en el flujo crítico de compra, entra en cada merge. Un escenario largo de capacidad corre semanal. Las extensiones xk6 agregan salida a Prometheus cuando el equipo quiere gráficos más allá del reporte de CI. John Allspaw, en The Art of Capacity Planning (O'Reilly, 2008), defiende probar la carga del crecimiento previsto, no solo la de hoy.

Punto de saturación y qué observar

El RPS sube con los VUs hasta un techo; después, la latencia dispara y el RPS se estanca. Ese techo suele vivir en el pool de conexiones de la base de datos, antes de vivir en el CPU de la aplicación. Observas la cola de conexiones, el uso del pool y la latencia p99 durante el test, y amarras el script a un trace por ID de request para convertir cada pico en una investigación. Un escenario sin observabilidad se vuelve un número suelto que nadie puede explicar en la reunión de review.