Te piden asegurar que el e-commerce aguante el Black Friday. ¿Cómo planificás las pruebas de performance y qué métricas mirás?

1. Objetivos medibles. Con negocio y analítica defino la carga esperada (usuarios concurrentes, RPS pico, por ejemplo el pico del año anterior x3) y los SLO: p95 menor a 500 ms en checkout y una tasa de error menor al 1%. Sin criterios, no hay forma de dar el pass/fail.

2. Escenarios realistas. A partir de logs armo el mix de tráfico: navegar, buscar, carrito, checkout, con think time y datos variados (no siempre el mismo producto, para no medir solo la caché).

3. Tipos de prueba:

• Load: carga esperada sostenida.
• Stress: subir hasta romper, para conocer el límite y cómo falla y se recupera.
• Spike: salto brusco, como cuando arranca la oferta; valida el autoscaling.
• Soak: horas a carga media para detectar memory leaks y agotamiento de conexiones.

4. Entorno. Uso uno lo más parecido posible a producción, aislado. Los servicios de terceros (pasarela de pagos) se reemplazan por mocks: no se le genera carga a nadie sin autorización escrita.

5. Métricas. Miro percentiles (p95/p99), no promedios, que esconden la cola; también throughput y errores. Del lado servidor reviso CPU, memoria, GC, pool de conexiones de la base, queries lentas, colas y latencia de dependencias. Para correlacionar uso APM o trazas.

export const options = {
  stages: [{ duration: '5m', target: 2000 }, { duration: '20m', target: 2000 }],
  thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'] },
};

6. Iterar. Tomo una línea base, identifico el cuello de botella, se corrige y vuelvo a medir. Además dejo un test de carga reducido en el pipeline para detectar regresiones de performance antes de la fecha.

Reportar promedios en lugar de percentiles, probar con un único escenario repetitivo que solo mide la caché, no definir SLO previos o generar carga sobre servicios de terceros o producción sin autorización.