Resumen ejecutivo
✓ 9 de 9 pruebas superadas
Decisión arquitectónica verificable, no una caja negra
Recomendación actual
Calculando escenario inicial…
1. Contexto y Configuración del Proyecto
Bogotá Segura (NexoTech) es un prototipo académico de seguridad ciudadana que integra reportes comunitarios, mapas de calor delictivo y cálculo de rutas seguras.
Nota de alcance: esta aplicación es una prueba de concepto tecnológica. No es un canal oficial de despacho policial ni reemplaza los servicios de emergencia.
Configuración editable del proyecto
Registre el contexto, los usuarios, el requisito prioritario y las restricciones que orientarán la decisión arquitectónica.
Objetivo del simulador
Apoyar la selección de una arquitectura de software mediante la comparación de indicadores cuantificables de rendimiento, disponibilidad, escalabilidad y costo.
Alternativas evaluadas
- Monolito tradicional: aplicación centralizada con menor complejidad operativa y capacidad limitada de escalamiento.
- Arquitectura modular + BaaS: aplicación modular apoyada en servicios administrados de autenticación, datos, almacenamiento y comunicación en tiempo real.
- Microservicios + eventos: servicios independientes comunicados mediante mecanismos asíncronos y eventos.
2. Configuración de Variables de Entrada
Seleccione un escenario predefinido o modifique las variables para crear un escenario personalizado.
Usuarios activos simultáneamente y generando peticiones.
Consultas, reportes o validaciones realizadas por cada usuario durante un minuto.
Operaciones que requieren transferencia y almacenamiento multimedia.
Retardo de red entre el cliente y la infraestructura.
Requisito obligatorio para descartar alternativas no aptas.
3. Comparación de Alternativas Arquitectónicas
La tabla presenta los resultados calculados para cada arquitectura bajo las mismas condiciones.
| Indicador cuantificable | A. Monolito Tradicional | B. Modular + BaaS (Supabase) | C. Microservicios + Eventos |
|---|---|---|---|
| Latencia media estimada (ms) | - | - | - |
| Throughput servido (req/s) | - | - | - |
| Utilización estimada (%) | - | - | - |
| Disponibilidad estimada (%) | - | - | - |
| Costo mensual estimado (USD) | - | - | - |
| Margen de escalabilidad (%) | - | - | - |
| Cumplimiento de requisitos | - | - | - |
Cambio frente a la ejecución anterior
Ejecute otro escenario para comparar automáticamente qué cambió y por qué.
4. Visualización Comparativa
Las barras representan los resultados estimados para el escenario seleccionado. Cada indicador utiliza su propia escala.
Latencia estimada (ms)
Costo mensual estimado (USD)
Disponibilidad estimada (%)
Puntaje total (0 a 100)
5. Dictamen y Recomendación Explicable
La recomendación considera únicamente las arquitecturas que cumplen los requisitos obligatorios del escenario.
Pendiente de ejecución de simulación.
6. Metodología y Fórmulas del Modelo
El modelo transforma las variables de entrada en indicadores comparables. Las fórmulas se aplican de la misma manera a las tres alternativas, cambiando sus parámetros técnicos.
1. Carga bruta
Cantidad total de solicitudes generadas durante un minuto.
Fórmula:
cargaBruta = usuariosConcurrentes × solicitudesPorUsuarioMinuto
2. Factor por fotografías
Las fotografías requieren transferencia, almacenamiento y procesamiento adicionales.
Fórmula:
factorFoto = 1 + 0.8 × (porcentajeConFoto / 100)
3. Carga equivalente
Ajusta la carga bruta según las operaciones multimedia.
Fórmula:
cargaEquivalente = cargaBruta × factorFoto
4. Unidades requeridas
Calcula las instancias necesarias dentro del máximo permitido.
Fórmula:
unidades = ceil(cargaEquivalente / capacidadPorInstancia)
5. Utilización
Porcentaje de capacidad activa utilizado.
Fórmula:
utilización = (cargaEquivalente / capacidadEfectiva) × 100
6. Penalización por cola
Se aplica al superar el 70% de utilización.
si utilización ≤ 70: penalización = 0
si utilización > 70: penalización = 1.5 × (utilización - 70)²
7. Latencia estimada
Combina red, procesamiento, saltos y cola.
latencia = latenciaRed + latenciaBase + (saltos × penalizaciónSalto) + penalizaciónCola
8. Throughput
Solicitudes atendidas por segundo sin superar la capacidad.
throughput = min(cargaEquivalente, capacidadEfectiva) / 60
9. Disponibilidad estimada
Disminuye cuando la utilización supera el 85%.
disponibilidad = disponibilidadBase - max(0, utilización - 85) × 0.02
10. Costo mensual
Incluye costo base, unidades adicionales y operaciones multimedia.
costo = costoBase + (unidades - 1) × costoUnidad + usuarios × (porcentajeFoto / 100) × 0.01
11. Margen de escalabilidad
Capacidad máxima que permanece disponible.
margen = ((capacidadTotal - cargaEquivalente) / capacidadTotal) × 100
12. Cumplimiento obligatorio
Exige disponibilidad suficiente, ausencia de saturación y costo dentro del presupuesto registrado.
cumple = disponibilidadEstimada ≥ disponibilidadMínima y utilización < 100% y costo ≤ presupuesto
Relación entre variables e indicadores
| Variable | Indicadores afectados | Relación utilizada |
|---|---|---|
| Usuarios concurrentes | Carga, utilización, throughput, costo y latencia | Más usuarios generan más solicitudes y consumo de capacidad. |
| Solicitudes por usuario/minuto | Carga, unidades, utilización y saturación | Aumenta directamente la carga bruta. |
| Operaciones con fotografía | Carga equivalente, utilización y costo | Aplica un multiplicador de carga y un costo multimedia. |
| Latencia de red | Latencia total | Se suma directamente al tiempo estimado. |
| Disponibilidad mínima | Cumplimiento y descarte | Actúa como requisito obligatorio. |
| Presupuesto máximo | Cumplimiento y recomendación | Descarta cualquier alternativa cuyo costo estimado supere el límite registrado. |
Parámetros técnicos por arquitectura
| Parámetro | Monolito | Modular + BaaS | Microservicios + Eventos |
|---|---|---|---|
| Latencia base | 45 ms | 70 ms | 90 ms |
| Saltos internos | 1 | 2 | 4 |
| Penalización por salto | 8 ms | 10 ms | 12 ms |
| Capacidad por instancia | 600 solicitudes/min | 1400 solicitudes/min | 2200 solicitudes/min |
| Máximo de unidades | 3 | 12 | 40 |
| Disponibilidad base | 99,00% | 99,70% | 99,90% |
| Costo base mensual | USD 10 | USD 25 | USD 80 |
| Costo por unidad adicional | USD 12 | USD 18 | USD 30 |
| Nivel de complejidad | 2 de 5 | 3 de 5 | 5 de 5 |
| Índice académico de seguridad | 82 de 100 | 94 de 100 | 97 de 100 |
Origen y alcance de los parámetros
Los valores numéricos de capacidad, disponibilidad, latencia y costo son supuestos académicos definidos por el equipo para demostrar el comportamiento del modelo. No constituyen mediciones de producción ni cotizaciones comerciales.
Sistema de puntuación multicriterio
Los siguientes son los pesos base. El atributo de calidad prioritario registrado por el usuario aumenta a 35% y el 65% restante se redistribuye proporcionalmente entre los demás criterios. De esta forma, la configuración del proyecto sí modifica la decisión.
| Criterio | Peso | Interpretación |
|---|---|---|
| Latencia | 25% | Una latencia menor recibe mejor calificación. |
| Disponibilidad | 25% | Una disponibilidad mayor recibe mejor calificación. |
| Escalabilidad | 20% | Un margen mayor recibe mejor calificación. |
| Costo | 15% | Un costo menor recibe mejor calificación. |
| Seguridad y cifrado | 10% | Se usa un índice académico diferenciado (82, 94 y 97) según aislamiento, servicios administrados y controles distribuidos supuestos. |
| Simplicidad operativa | 5% | Una complejidad menor recibe mejor calificación. |
Fórmula del puntaje
puntaje = Σ (indicadorNormalizado × pesoActivo)
Con la configuración inicial, disponibilidad utiliza 35% y los demás pesos se redistribuyen. La recomendación corresponde al mayor puntaje entre las alternativas que cumplen los requisitos obligatorios.
7. Supuestos, Limitaciones y Pruebas Documentadas
Supuestos y limitaciones
- La penalización de cola crece de forma cuadrática al superar 70% de utilización.
- Las fotografías introducen un multiplicador de carga de hasta 1,8.
- El escalamiento horizontal está limitado por arquitectura.
- Los costos son estimaciones académicas.
- No se simulan fallos reales de red, ataques ni distribución geográfica.
- La disponibilidad calculada no sustituye pruebas reales de carga o tolerancia a fallos.
Casos de prueba documentados
- Entrada negativa: rechazo de usuarios menores que 10.
- Campo vacío: bloqueo de la ejecución sin datos obligatorios.
- Determinismo: iguales entradas producen iguales resultados.
- Sensibilidad multimedia: más fotografías aumentan carga y costo.
- Saturación: se penalizan latencia y disponibilidad.
- Criterio de corte: se descartan alternativas que no cumplen.
- Sin alternativa apta: el sistema no fuerza una recomendación inválida.
Interpretación responsable
El simulador es una herramienta de apoyo. Una implementación real requiere pruebas de carga, seguridad, observabilidad, análisis de costos y validación de requisitos.
8. Comparación Consolidada de Escenarios
Ejecute los tres escenarios predefinidos con la misma configuración del proyecto para demostrar cómo la demanda modifica los indicadores y la recomendación.
| Escenario | Carga equivalente | Alternativas aptas | Recomendación | Motivo principal |
|---|---|---|---|---|
| Presione “Comparar los tres escenarios” para calcular el resumen. | ||||
La comparación consolidada quedará registrada aquí.
9. Simulación Temporal y Análisis de Resiliencia
Este modo representa la evolución del sistema durante intervalos de tiempo simulados. Cada segundo de reproducción equivale a un minuto del modelo académico; los valores no proceden de servidores reales.
Modo experimental:
la demanda crecerá desde un nivel inicial hasta una hora pico y luego
disminuirá. Durante la ejecución se recalcularán las tres arquitecturas.
Configuración de la simulación temporal
Cantidad total de intervalos que recorrerá el modelo.
Demanda al comenzar y al finalizar la simulación.
Valor máximo de usuarios concurrentes durante la ejecución.
Momento en el que la demanda alcanza su valor máximo.
Controla la velocidad visual, no las fórmulas del modelo.
Forma en la que cambiarán los usuarios durante el tiempo.
Simular degradación temporal de la red
Aumentará la latencia durante una parte de la ejecución.
Simular aumento temporal de fotografías
Representará un incremento de reportes con evidencia.
Preparada para iniciar
Minuto 0 de 30
Indicadores en vivo
Estado actual por arquitectura
Monolito
- Utilización
- -
- Latencia
- -
- Disponibilidad
- -
- Estado
- En espera
Modular + BaaS
- Utilización
- -
- Latencia
- -
- Disponibilidad
- -
- Estado
- En espera
Microservicios + eventos
- Utilización
- -
- Latencia
- -
- Disponibilidad
- -
- Estado
- En espera
Historial temporal
Los gráficos muestran en tiempo real la evolución de utilización, latencia, throughput y disponibilidad de las tres arquitecturas.
Utilización frente al tiempo
Latencia frente al tiempo
Throughput frente al tiempo
Disponibilidad frente al tiempo
Bitácora de eventos
- La simulación todavía no ha comenzado.
Resumen final
Al finalizar se mostrarán estabilidad, primera saturación, máximos observados y recomendación temporal.
10. Bibliografía indicada en la guía
Estas fuentes orientan los criterios de rendimiento, escalabilidad, modularidad y separación de responsabilidades. Los números del simulador continúan siendo supuestos académicos transparentes, no datos copiados de los artículos.
From Monolithic Systems to Microservices: A Comparative Study of Performance
Tapia, F., Mora, M. Á., Fuertes, W., Aules, H., Flores, E. y Toulkeridis, T.
Abrir artículo y DOIMonolithic vs. Microservice Architecture: A Performance and Scalability Evaluation
Blinowski, G. J., Ojdowska, A. y Przybylek, A. Vol. 10, pp. 20357–20374.
Abrir artículo y DOIA Comparative Review of Microservices and Monolithic Architectures
Al-Debagy, O. y Martinek, P. arXiv:1905.07997.
Abrir artículoMVC Architecture: A Comparative Study Between Laravel Framework and Slim Framework in Freelancer Project Monitoring System Web Based
Sunardi, A. y Suharjito. Vol. 157, pp. 134–141.
Abrir artículo y DOICómo se conectan con el simulador
La literatura evidencia que no existe una arquitectura universalmente superior: el resultado depende de carga, entorno, costo, tecnología y forma de escalamiento. Por eso este prototipo compara escenarios y declara sus supuestos en vez de presentar una respuesta fija.