Arquitectura auditable · Unidad 12 de 13
Los experimentos revelan, no confirman
Un gate de admisión puede tener su lógica probada en unidad —rechazar sobre el límite, liberar el slot, respetar la prioridad— y aun así fallar por tres razones que ninguna prueba unitaria puede ver. Un contador de ocupación con TTL de seguridad se resetea a mitad de vuelo si la carga se sostiene más que el TTL, y readmite de más: solo aparece pasado ese umbral de tiempo, nunca en una corrida corta. Un gate colocado después de la primera consulta a la base de datos no protege nada: la carga ya tocó el recurso antes de que el gate opine. Y en un modelo shared-nothing, abrir una conexión por petición agota los puertos efímeros a suficiente tasa. Los tres son invisibles al test de lógica y al benchmark de menos de 30 s; los tres se vuelven obvios con carga real y sostenida.
Al terminar podrás
- Reconocer por qué una máquina de capacidad con tests unitarios verdes puede fallar bajo carga sostenida.
- Diseñar la validación para revelar el comportamiento que la hipótesis no explica, no para confirmarla.
Entender
Un gate de admisión puede tener su lógica probada en unidad —rechazar sobre el límite, liberar el slot, respetar la prioridad— y aun así fallar por tres razones que ninguna prueba unitaria puede ver. Un contador de ocupación con TTL de seguridad se resetea a mitad de vuelo si la carga se sostiene más que el TTL, y readmite de más: solo aparece pasado ese umbral de tiempo, nunca en una corrida corta. Un gate colocado después de la primera consulta a la base de datos no protege nada: la carga ya tocó el recurso antes de que el gate opine. Y en un modelo shared-nothing, abrir una conexión por petición agota los puertos efímeros a suficiente tasa. Los tres son invisibles al test de lógica y al benchmark de menos de 30 s; los tres se vuelven obvios con carga real y sostenida.
La lección no es 'haz más tests'; es para qué existe un experimento. No está para CONFIRMAR la hipótesis —'la máquina funciona, el benchmark lo prueba'— sino para REVELAR el comportamiento que la hipótesis todavía no explica. La herramienta de validación más valiosa es la capaz de observar un fenómeno que el resto de las pruebas no puede: el test unitario mide la lógica; el benchmark sostenido mide lo que emerge del tiempo, la concurrencia y las conexiones reales. Cuando el resultado refuta la hipótesis cómoda, ese es el valor, no el fracaso. De ahí la disciplina de evidencia: 'hecho' no es una afirmación, es un artefacto reproducible bajo las condiciones donde el sistema realmente corre —sostener la carga por encima de cualquier TTL, medir dónde se forma la cola, contar las conexiones reales.
Ver
Abrir la radiografía del runtime
La radiografía muestra que cada camino de una operación deja un rastro distinto —la misma disciplina de mirar el comportamiento real, paso a paso, que un benchmark sostenido aplica a la capacidad.
Hacer
Ejecuta la práctica en tu checkout y conserva la salida como evidencia.
Verificar
Demuestra que puedes aplicar la unidad. El progreso solo avanza al aprobar la evaluación.
Criterios evaluados
- Da un ejemplo de un defecto de capacidad que un test unitario con lógica verde no puede exhibir, y di qué condición del benchmark lo revela.
- Explica la diferencia entre un experimento que confirma la hipótesis y uno que revela lo que la hipótesis no explica.
Fuentes primarias
- k6 — pruebas de carga
- Radiografía del runtime (Academy)
Contenido verificado: 2026-07-23