Rendimiento y escalado

Skrum es el plano de control de proyectos con IA todo en uno — chat de equipo, tareas y sprints, reuniones de vídeo nativas y actividad de código entrante en un solo espacio de trabajo, con cada acción de la IA a la espera de un sí humano.

Skrum está diseñado para mantenerse ágil cuando un espacio de trabajo crece y cuando la infraestructura tiene un mal día. Esta página documenta los números concretos, el modelo de caché y los modos de fallo.

Umbrales de carga

Los escenarios opcionales de k6 en load/ mantienen a Skrum en estos objetivos frente al stack compuesto con proveedores simulados deterministas:

• Fan-out en tiempo real — 500 clientes de socket concurrentes en un canal, latencia p95 mensaje-a-fan-out ≤ 250 ms, tasa de errores < 0.1%.
• POST de mensaje — p95 ≤ 200 ms a 50 rps, tasa de errores < 0.5%.
• Lectura de tablero (GET /api/tasks?projectId=…) — p95 ≤ 150 ms a 100 rps, tasa de errores < 0.5%.
• Búsqueda (GET /api/search) — p95 ≤ 300 ms a 50 rps, tasa de errores < 1%.
• Resumen de inicio (GET /api/home/summary) — p95 ≤ 200 ms a 100 rps, tasa de errores < 0.5%.

Caché de lectura pasante

Una pequeña caché de lectura pasante respaldada por Redis cubre tres rutas críticas: la lista de canales por espacio de trabajo, las proyecciones del tablero de proyectos y el resumen del panel/inicio. Cada clave lleva como prefijo el accountId del espacio de trabajo — un espacio de trabajo solo puede leer sus propios datos cacheados. La invalidación es dirigida por eventos desde la columna vertebral de tiempo real (message.posted, channel.*, task.*), con un TTL corto como respaldo. La caché almacena únicamente proyecciones ya autorizadas y no secretas.

Resiliencia ante el caos

Cuando una dependencia falla, Skrum falla de forma cerrada en lugar de escribir parcialmente o filtrar datos.

• Redis caído. El tiempo real y la caché se degradan; REST sigue sirviendo la fuente de verdad desde Mongo y Postgres. Los limitadores de tasa fallan de forma segura (deniegan, nunca abren la puerta).
• Mongo o Postgres inalcanzables. Las rutas devuelven un error localizado de clase 503 — sin caída no gestionada y sin escritura parcial.
• MinIO o LiveKit caídos. Las cargas de archivos y las reuniones fallan de forma cerrada con un error localizado; el resto de la app sigue funcionando. Consulta Copia de seguridad y restauración.

Cuando la dependencia vuelve, el servicio se reanuda automáticamente — sin necesidad de reinicio manual.

Preguntas frecuentes

• ¿Ejecuto la suite de k6 en CI? Sí, tras un trabajo opcional. Los escenarios de carga nunca bloquean una pull request normal.
• ¿Puedo aumentar el TTL de la caché? El TTL es deliberadamente corto. La invalidación dirigida por eventos es la vía principal de corrección; el TTL es solo un respaldo por si Redis se cae.
• ¿Puede la caché filtrar datos entre espacios de trabajo? No — cada clave lleva como prefijo el accountId y un test dedicado demuestra el aislamiento entre inquilinos.

Ver también: Documentación de Skrum