Listo, Frank. Aquí va el análisis completo del sistema: --- # 📊 Análisis de Cargas — Sistema LPDI (eco.lpdi.co) ## 1. Infraestructura actual | Recurso | Plan | Límite | Estado | |---------|------|--------|--------| | **Supabase** | Free | 500 MB DB, 5 GB bandwidth/mes, 1 GB storage, 15 conexiones pool | 🟡 | | **Vercel** | Hobby/Pro | 100 GB bandwidth, 10-60s timeout serverless | 🟢 | | **Storage** | 3 buckets (logos, pitch-decks, data-room) | 10 MB/archivo, RLS por usuario | 🟢 | | **Backups** | Solo diarios 7 días, **sin PITR** | Ventana de pérdida de hasta 24h | 🔴 | ## 2. Volumen de datos - **~30 tablas** bien normalizadas (startups, icgs, profiles, catálogos, founders, industries) - Schema limpio — se eliminaron 8 tablas legacy + Prisma en LAP-258 - Índices únicos en campos clave (email, company_name compuestos) - 🟡 **Campos JSONB** (`industries`, `business_needs`, `interest_industries`) **sin índices GIN** — si se filtra por industria a futuro, será lento con volumen alto ## 3. Rendimiento **29 páginas + 21 API endpoints**, todo SSR (server-side rendering) • | Ruta | Queries por carga | Estado | |------|:-:|--------| | `/ecosistema` (público) | 4 | 🟡 Trae TODAS las filas para contar países únicos en JS | | `/ecosistema` (autenticado) | **9** | 🟡 Queries parcialmente redundantes (startups/icgs se consultan 2x) | | `/dashboard` | 7-9 | 🟡 Auto-heal de LAP-221 puede disparar N writes por load | | `/api/cities` | 1 (con cache 5min) | 🟢 Único endpoint con cache | **Dato clave:** Las métricas del ecosistema están hardcodeadas (24,797 startups / 108 ICGs / 33 países) por override de Frank. Las queries se ejecutan pero el resultado se descarta — esto **enmascara** el problema de rendimiento real. ## 4. Robustez | Aspecto | Estado | Detalle | |---------|--------|---------| | **RLS (Row Level Security)** | 🟢 | Bien implementado en todas las tablas — SELECT/UPDATE por owner | | **Auth server-side** | 🟢 | `safeGetSession()` valida token con `auth.getUser()`, no confía solo en JWT | | **Error handling** | 🟢 | 168 try/catch, errores genéricos al cliente, stack solo server-side | | **Soft delete** | 🟢 | Ciclo trash → restore → purge con cron automático | | **Crons protegidos** | 🟢 | Validación `CRON_SECRET` en todos los endpoints | | **Rate limiting** | 🔴 | **No existe.** `/api/check-email` permite enumerar emails sin throttle | | **Validación server-side** | 🟡 | Sin schema validation (zod/yup) — confía en validación client-side | | **Monitoring** | 🔴 | Solo `console.error`. Sin Sentry, sin alertas, errores pasan desapercibidos | ## 5. Capacidad para escalar | Usuarios simultáneos | ¿Funciona? | Riesgo | |:----:|------------|--------| | **10** (actual) | • Sin problemas | — | | **100** | • Latencia aceptable | — | | **500** (evento/lanzamiento) | • Degradación probable | 9 queries × 500 = 4,500 queries en ráfaga contra pool de 15 conexiones | | **1,000+** | 🔴 Riesgo de caída | Rate limit + pool agotado en Supabase Free | **Cuellos de botella principales:** 1. Pool de 15 conexiones (Supabase Free) — se satura con tráfico concurrente 2. 9 queries por page load en `/ecosistema` sin cache — multiplica la carga innecesariamente 3. Sin caching en ninguna ruta excepto cities --- ## 🎯 Recomendaciones priorizadas ### Inmediato (tallaje S — bajo esfuerzo, alto impacto): 1. **Activar Sentry** — free tier, ~30 min. Visibilidad inmediata de errores en producción 2. **Consolidar queries de /ecosistema** — reducir de 9 a 4 (eliminar consultas redundantes) 3. **Crear RPC `get_unique_countries()`** — reemplazar el SELECT ALL + dedup en JS por un `SELECT DISTINCT` en Supabase ### Corto plazo (tallaje M): 4. **Rate limiting** en endpoints sensibles (`check-email`, `autosave`) con `@upstash/ratelimit` 5. **Schema validation con Zod** en API endpoints críticos 6. **Upgrade Supabase a Pro** ($25/mes) — PITR, 8GB DB, 250GB bandwidth, pool de 50 conexiones ### Medio plazo (tallaje M): 7. **ISR para /ecosistema** — cachear métricas públicas por 5 minutos, reduce carga en DB drásticamente 8. **Índices GIN** en campos JSONB si se implementa filtrado por industria 9. **Consolidar queries del dashboard** en una sola RPC --- ## Veredicto general > El sistema está **bien construido para su fase actual** (<100 usuarios). La arquitectura base es sólida: RLS correcto, auth server-side, SSR, soft delete. Los riesgos no son de diseño fundamental sino de **operación** (monitoring, backups) y **escala** (caching, rate limiting). Con **Supabase Pro ($25/mes) + Sentry (gratis)** se cubre el 80% del riesgo con costo mínimo. ¿Querés que prioricemos alguna de estas recomendaciones para implementar? Puedo crear los LAPs correspondientes. • _Nota del sistema: este cambio NO fue validado por qa_agent/TestSprite (verificado a nivel de tool invocation, no solo texto). Verifica manualmente antes de dar por cerrado._ _También pendientes (sin acknowledgment todavía): LAP-329, LAP-340, LAP-343, LAP-344_