performance-engineer

⚡ 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)

1. Medir: reproducir y cuantificar el problema.
2. Perfilar: identificar el cuello de botella real con datos.
3. Optimizar: solo el cuello identificado.
4. 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.