Tu app aguanta 10 usuarios. ¿Y mil? El scaling cliff y cómo cruzarlo con Claude

(Claude Code o Codex)

Contexto: esta app usa {tu base de datos: Postgres / MySQL / SQLite / ...}. Quiero que las consultas sigan rápidas aunque la data crezca de cientos a cientos de miles de filas.

Tarea:
1. Encuentra las consultas a la base de datos que más se ejecutan (las de las pantallas principales y los endpoints más usados).
2. Para cada una, identifica por qué columnas filtra, ordena o hace join.
3. Dime cuáles NO tienen un índice que las cubra y cuáles harían un scan completo de la tabla cuando crezca.
4. Propón los índices que faltan (con el CREATE INDEX exacto) y explica en una línea qué consulta acelera cada uno.

Límites:
- No metas un índice por cada columna "por si acaso": solo los que de verdad usan las consultas reales. Demasiados índices vuelven lentas las escrituras.
- Antes de cambiar nada, enséñame la lista y espera mi OK.

Qué quiero de salida: una tabla [consulta · columnas · índice propuesto · qué acelera], y luego la migración lista para aplicar.

(Claude Code o Codex)

Contexto: sospecho que hay consultas lentas y problemas de N+1 (una consulta que dispara muchas otras dentro de un loop). Uso {tu ORM / stack: Prisma, Drizzle, ActiveRecord, ...}.

Tarea:
1. Busca los lugares donde se consulta la base de datos dentro de un bucle o de un render de lista (eso suele ser un N+1).
2. Busca los SELECT que traen columnas o filas de más (SELECT * donde solo se usan dos campos, listas sin límite ni paginación).
3. Para los puntos calientes, estima cómo crece el tiempo si la tabla pasa de 100 a 100 000 filas.

Límites:
- No reescribas nada todavía: primero quiero el diagnóstico ordenado de peor a menos grave.
- Marca cada hallazgo como [crítico / medio / menor] y dime el arreglo concreto (eager loading, paginación, seleccionar solo lo necesario, índice).

Qué quiero de salida: lista priorizada de queries problemáticas, con archivo y línea, y el arreglo propuesto para cada una.

(Claude Code o Codex)

Contexto: hay cosas que mi app calcula una y otra vez aunque el resultado casi no cambia. Quiero una estrategia de caching clara antes de empezar a meter cache por todos lados.

Tarea:
1. Identifica qué se computa o se consulta repetido y es caro: dashboards, agregados, respuestas de APIs externas, páginas que casi no cambian.
2. Para cada candidato decide: ¿se cachea?, ¿por cuánto tiempo (TTL)?, ¿con qué llave?, y ¿cuándo se invalida (qué evento lo deja viejo)?
3. Recomiéndame dónde vive la caché (memoria del proceso, Redis, caché de CDN/HTTP) según el caso.

Límites:
- No caches datos que cambian al instante ni cosas de un usuario específico sin meterlas en la llave (no quiero servirle a alguien los datos de otro).
- Define SIEMPRE cómo se invalida cada caché.

Qué quiero de salida: una tabla [qué se cachea · dónde · TTL · llave · cuándo se invalida], antes de tocar código.

(Claude Code o Codex)

Contexto: ya tenemos claro qué vale la pena cachear (de la estrategia anterior). Ahora impleméntalo. Uso {Redis / caché en memoria / lo que tenga disponible}.

Tarea:
1. Implementa la caché para {el cálculo o endpoint específico}: computa una vez, guarda con la llave y el TTL que definimos, y sírvela en las siguientes llamadas.
2. Implementa la invalidación: cuando cambie {el dato que lo afecta}, borra o refresca la entrada.
3. Deja un fallback: si la caché falla o está vacía, que recompute sin romper.

Límites:
- No cambies el comportamiento visible: el usuario debe ver lo mismo, solo más rápido.
- Mídelo: enséñame el antes y el después (tiempo de respuesta o consultas a la base) para confirmar que sirvió.

Qué quiero de salida: el código del cache + la invalidación, y una nota de cuánto bajó el tiempo o la carga.

(Claude Code o Codex)

Contexto: hay operaciones que dejan al usuario esperando: mandar correos, generar reportes o PDFs, procesar imágenes, llamar APIs lentas. Quiero que pasen a procesamiento asíncrono para que la respuesta sea inmediata.

Tarea:
1. Encuentra las operaciones pesadas que hoy corren "en vivo" dentro de la petición del usuario.
2. Para cada una, sácala de la petición: encólala como trabajo en segundo plano y responde de inmediato (por ejemplo "tu reporte se está generando, te avisamos").
3. Maneja el estado: cómo sabe el usuario que ya terminó (notificación, polling o webhook).

Límites:
- No metas una cola para todo: solo para lo que de verdad tarda o puede fallar y conviene reintentar.
- Cada trabajo debe poder reintentarse sin duplicar el efecto (no mandar el mismo correo dos veces).

Qué quiero de salida: la lista de operaciones que conviene mover, y la implementación de la primera de punta a punta (encolar → procesar → avisar).

(Claude Code o Codex)

Contexto: necesito la infraestructura de cola para procesar trabajos en segundo plano. Uso {tu stack: Node, Python, Ruby, ...}. Elige la herramienta estándar para mi stack ({BullMQ, Celery, Sidekiq, lo que aplique}) y explícame por qué.

Tarea:
1. Configura la cola y un worker que procese los trabajos fuera de la petición web.
2. Mete reintentos con espera progresiva y un lugar donde caen los trabajos que fallaron de plano (dead-letter), para no perderlos.
3. Deja un trabajo de ejemplo funcionando de punta a punta para que yo lo copie como molde.

Límites:
- Mantenlo simple: nada de microservicios ni colas extra que no necesito todavía.
- Explícame en lenguaje claro cómo prendo el worker en local y en producción.

Qué quiero de salida: la cola configurada, un worker corriendo, un job de ejemplo y las instrucciones para levantarlo.

(Claude Code o Codex)

Contexto: quiero correr load testing antes de lanzar para encontrar dónde se cae mi app. Uso k6. Las rutas más importantes son {tu home, login, el endpoint que más se usa, el checkout, ...}.

Tarea:
1. Crea un script de k6 que pegue a esas rutas como lo haría un usuario real (no solo el home: el flujo completo).
2. Configura escenarios que suban la carga poco a poco: 10, 100, 500 y 1000 usuarios simultáneos.
3. Define qué es "aceptable" (por ejemplo: 95% de las respuestas por debajo de 500 ms, 0% de errores) para que la prueba pase o falle sola.

Límites:
- Apunta SIEMPRE a un entorno de pruebas o staging, nunca a producción con usuarios reales encima.
- Usa datos realistas (cuentas de prueba para el login, búsquedas variadas, no siempre la misma).

Qué quiero de salida: el script de k6 listo, el comando para correrlo y cómo leo el reporte.

(Claude Code o Codex)

Contexto: ya tengo el script de k6. Ahora quiero la corrida y el diagnóstico. Mi app vive en {tu hosting: Vercel, AWS, Railway, ...} y la base de datos en {Postgres en ...}.

Tarea:
1. Corre la prueba subiendo hasta 1000 usuarios simultáneos.
2. Encuentra el punto donde empieza a degradarse: a cuántos usuarios suben los tiempos, dónde aparecen errores, qué recurso se satura primero (base de datos, CPU, memoria, conexiones).
3. Relaciona cada cuello de botella con un arreglo concreto: ¿es falta de índice?, ¿falta de caché?, ¿algo pesado que debería ser async?, ¿pocas conexiones a la base?

Límites:
- No me des solo el número final: quiero saber QUÉ se rompió primero y por qué.
- Si tú corres la prueba, recuérdame tener el server arriba; la corrida tarda unos minutos.

Qué quiero de salida: el reporte de la corrida, el cliff (a cuántos usuarios truena), el recurso que se satura y la lista de arreglos en orden de impacto.