Escalando espectadores en tiempo real
Medir honestamente la infraestructura de tiempo real de UFT — qué mostraron realmente las pruebas de carga, y qué encontró el análisis de tiempos de despliegue.
UFT corre en un único droplet de DigitalOcean que aloja Postgres, la API, NATS, Redis, el servicio de feed social, y streaming en vivo, todo junto. El tráfico de espectadores alrededor de partidos en vivo es inherentemente más picudo que el uso administrativo estable, y en vez de adivinar cómo se sostiene el setup actual, el objetivo fue medirlo de verdad — conexiones, latencia de unión a sala, tasa de error, y dónde los propios despliegues pierden tiempo.
Un primer intento de test de carga usó una herramienta genérica (k6) que se conectó al namespace equivocado de Socket.io, no produjo actividad visible en el backend, y parecía un fracaso total. En vez de confiar en esa señal, escribí scripts de carga en Node usando exactamente la misma librería socket.io-client que usa el frontend real, así el tráfico de prueba es indistinguible del tráfico real a nivel de protocolo. Construí escenarios por niveles y específicos por propósito en vez de un solo test genérico: partido único, 4 partidos simultáneos, y un escenario de "dashboard de todos los partidos en vivo", cada uno escalando en niveles ligero/medio/pesado/estrés (10/25/50/100 espectadores por partido). Por separado, se midió el tiempo de despliegue en sí en vez de asumir que era aceptable: un análisis de causa raíz desglosó un despliegue de 20–45 minutos fase por fase.
Los scripts de carga hechos a mano requieren más mantenimiento que una herramienta lista para usar, pero fueron lo único que dijo la verdad acá — el falso negativo de la herramienta genérica habría llevado la investigación en la dirección equivocada. Del lado del despliegue, el arreglo (dejar de borrar el caché de build de Docker y de forzar un rebuild del frontend sin caché en cada despliegue) está identificado y se estima que ahorraría la mayor parte de los 20–45 minutos, pero todavía no se aplicó — una brecha real y abierta entre "documentado" y "hecho".
Tests de conexión: 100% de los espectadores se conectaron y se unieron a la sala de su partido exitosamente, 0 errores. Pero el tiempo promedio de conexión fue de ~3.9 segundos y el de unión a sala de ~1.9 segundos — contra el benchmark propio del equipo (menos de 500ms como "ideal"), eso se etiqueta honestamente como "alto", no aceptable. Tests de concurrencia dirigidos validaron por separado 100+ espectadores en una sola sala y 10+ partidos simultáneos con aislamiento de sala limpio, todos pasando. En despliegues: la cifra de 20–45 minutos se desglosó en cerca de 12–25 minutos solo para el build del frontend, causado por borrar la imagen anterior y deshabilitar el caché de build antes de cada despliegue. La corrección se validó antes que la latencia — un orden defendible, pero "funciona" y "es rápido" son barras genuinamente distintas, y ~3.9s es la brecha honesta entre ambas ahora mismo. La historia de las pruebas de carga es en sí la lección más grande: una herramienta de propósito general que no coincide con tu cliente real puede producir una señal confiada pero equivocada — probar con la librería cliente real fue lo que convirtió "parece roto" en "acá está el número real, y acá está el objetivo que no está cumpliendo".