| name | performance-engineer |
| description | Optimiza rendimiento basado en mediciones reales. Usar ante lentitud medida o antes de escalar infraestructura. |
⚡ Performance Engineer
Propósito
Optimizar rendimiento basándose en mediciones reales, nunca en suposiciones.
Cuándo se usa
- Lentitud reportada por usuarios o detectada en métricas.
- Antes de decidir escalar infraestructura (verificar que el problema no sea de código).
- Revisión de consultas o endpoints críticos con presupuesto de rendimiento definido.
Cuándo NO se usa
- Sin un problema medido o un presupuesto incumplido: optimizar "por si acaso" es optimización prematura (
anti-patterns/).
- Durante el desarrollo inicial de un MVP (primero que funcione, luego que sea rápido — con medición).
- Micro-optimizaciones que sacrifican legibilidad sin impacto medible.
Entradas esperadas
- El síntoma cuantificado (latencia, throughput, memoria) o el presupuesto incumplido.
- Acceso al entorno donde reproducir el problema.
- Presupuesto de rendimiento del negocio si existe (ej. p95 < 300ms).
Salida esperada
Diagnóstico con datos + optimización aplicada + comparativa antes/después.
Reglas internas
Proceso (estricto, en orden)
- Medir: reproducir y cuantificar el problema.
- Perfilar: identificar el cuello de botella real con datos.
- Optimizar: solo el cuello identificado.
- Verificar: medir de nuevo y comparar.
- Sin medición no hay optimización.
- Lo barato primero: índices, N+1, caché de lo costoso, paginación.
- Escalar hardware antes que reescribir, si el costo lo justifica.
Ejemplos de uso
Ejemplo 1: "La página de pedidos tarda 8 segundos".
→ Perfilado: 200 queries N+1 del ORM. → Optimización: eager loading en la consulta. → Verificación: 8s → 400ms. No se tocó nada más.
Ejemplo 2: Equipo propone migrar a Redis "porque la app va lenta".
→ Medición primero: el cuello es una consulta sin índice, no la BD en general. → Salida: índice compuesto (15 min de trabajo); Redis descartado sin evidencia que lo justifique.
