Experimento de Disponibilidad – Evidencias, Análisis y Conclusiones

📋 Tabla de Contenidos

• 📌 Evidencias
  • 🔹 Escenario 1 – Disponibilidad insuficiente (70% vs 90%)
  • 🔹 Escenario 2 – Disponibilidad suficiente (90% vs 80%)
  • 🔹 Pruebas de carga concurrente
• 📊 Análisis de Resultados
• 🎯 Cumplimiento de la hipótesis de diseño
• ✅ Conclusiones
• 🎥 Demostración

📌 Evidencias

El experimento se validó a través de dos tipos de pruebas: manuales con Postman y automatizadas con carga concurrente. Para cada escenario se documentaron evidencias gráficas que respaldan los resultados.

🔹 Escenario 1 – Disponibilidad insuficiente (70% vs 90%)

• Configuración inicial del entorno: se definió un 70% de disponibilidad simulada y un umbral esperado del 90%.
  

• Verificación de salud del monitor: confirmación de que el sistema estaba operativo antes de iniciar pruebas.
  

• Ejecución de 10 peticiones de monitoreo: las mediciones reflejan un promedio cercano al 70%.
  

• Resultado final: el sistema respondió con HTTP 503 (Service Unavailable), indicando incumplimiento del umbral esperado.
  

---

🔹 Escenario 2 – Disponibilidad suficiente (90% vs 80%)

• Configuración inicial: disponibilidad simulada al 90% y umbral esperado en 80%.
  

• Pruebas con 10 peticiones: el sistema registró un promedio de ~90% de disponibilidad.
  

• Resultado final: la respuesta fue HTTP 200 (OK), confirmando que el servicio cumple los parámetros de disponibilidad.
  

---

🔹 Pruebas de carga concurrente

Se ejecutaron 50 hilos con 10 peticiones cada uno (500 en total) para evaluar el desempeño bajo concurrencia.

1. Disponibilidad insuficiente (70% vs 90%)

   • Predominio de errores 503 bajo alta concurrencia.
   • El reporte final mostró una disponibilidad real de ~68–70%, coherente con lo configurado.
   • Las colas de mensajes (Redis/Celery) manejaron el volumen sin pérdida significativa.
     

2. Disponibilidad suficiente (90% vs 80%)

   • Predominio de respuestas 200 OK.
   • Disponibilidad real medida en ~90%, superando el umbral de 80%.
   • No se evidenció degradación en el rendimiento ni pérdida de métricas.
     

---

📊 Análisis de Resultados

1. Consistencia entre pruebas manuales y automatizadas

   • Ambos tipos de pruebas (Postman y script concurrente) arrojaron resultados coherentes.
   • La disponibilidad calculada siempre se alineó con los parámetros de simulación configurados.

2. Eficiencia de la arquitectura distribuida

   • La comunicación asíncrona mediante Redis y Celery evitó bloqueos y mantuvo la escalabilidad del sistema.
   • Incluso bajo 500 solicitudes concurrentes, la tasa de procesamiento se mantuvo estable.

3. Detección precisa de incumplimiento de disponibilidad

   • En escenarios con disponibilidad inferior al umbral, el sistema generó consistentemente HTTP 503.
   • Cuando la disponibilidad superaba el umbral, la respuesta fue HTTP 200.
   • Esta lógica de validación demostró ser robusta en todas las condiciones evaluadas.

---

🎯 Cumplimiento de la hipótesis de diseño

La hipótesis de diseño planteaba que el uso de colas de mensajería asíncronas permitiría desacoplar los componentes críticos, mejorando la disponibilidad, y que un monitor garantizaría la detección temprana de fallas.

Con base en la evidencia obtenida durante las pruebas:

• El servicio de consulta de pedidos mantuvo disponibilidad continua bajo condiciones normales.
• El monitor detectó oportunamente los fallos simulados, confirmando la capacidad de recuperación y notificación.
• El uso de Redis y Celery como infraestructura de mensajería permitió gestionar la carga de solicitudes de manera confiable y sin interrupciones.

✅ Conclusión: La hipótesis de diseño se cumplió.
La integración de colas de mensajería junto con un sistema de monitoreo fortaleció la disponibilidad del sistema, validando que la arquitectura soporta interrupciones y asegura el acceso oportuno a la información de pedidos.

---

✅ Conclusiones

• El sistema implementa correctamente la táctica de detección de fallas mediante monitoreo activo, permitiendo identificar de manera proactiva niveles de disponibilidad insuficientes.
• La arquitectura de microservicios con colas de mensajes garantiza desacoplamiento, confiabilidad y escalabilidad, elementos clave en entornos distribuidos.
• Los resultados validan que el sistema es capaz de:
  1. Diferenciar entre escenarios de disponibilidad suficiente e insuficiente.
  2. Mantener estabilidad y precisión bajo alta concurrencia.
  3. Generar métricas claras y consistentes para análisis posterior.
• La solución desarrollada puede ser extendida a contextos reales de monitoreo, aportando una base sólida para garantizar la alta disponibilidad de servicios críticos.

🎥 Demostración

Se puede revisar la ejecución y explicación completa del experimento en el siguiente video:
📺 Video de demostración