Modelos de arquitectura

Vista funcional

Vista despliegue

Diseño detallado de Arquitectura

Componente de Inventario

Vista Funcional

Vista de Secuencia

Diseño del Experimento 1 de arquitectura

Componente de Inventario: Disponibilidad bajo carga

Título del experimento	Disponibilidad bajo carga
Propósito del experimento	Evaluar cómo responde el sistema ante niveles crecientes de carga concurrente, identificando puntos de falla, degradación de servicio y límites de disponibilidad. El objetivo es validar que los componentes críticos mantienen su operatividad.
Resultados esperados	El sistema mantiene disponibilidad ≥ 99% bajo carga esperada y picos definidos
	Los tiempos de respuesta se mantienen dentro de los SLA establecidos
	Se identifican cuellos de botella en componentes específicos (si existen: ej. base de datos, colas)
	Se generan métricas para ajustar escalabilidad horizontal o vertical
Recursos requeridos	Python + FastAPI
	Docker
	Redis
	PostgreSQL
	k6
Elementos de arquitectura involucrados	Disponibilidad del componente de Inventario
Puntos de sensibilidad a probar	Sincronización de tablas de escritura y lectura
	Tiempos de respuesta
	Estabilidad del componente
Esfuerzo estimado	24 horas

Hipótesis de diseño	Si usamos CQRS + Redis Streams podemos asegurar la disponibilidad del sistema de inventario bajo una carga de trabajo alta
Puntos de sensibilidad	Latencia en el procesamiento de eventos
	Gestión de consumidores
	Consistencia eventual
	Carga canal de escritura
	Mecanismos de Backpressure
Historia de arquitectura asociada	HUA - Inventario: Alta disponibilidad del sistema
Nivel de incertidumbre	Alto, poca experiencia usando Redis, idempotencia y atomicidad

Patrones de Arquitectua asociados al experimento	Descripción
Colas de mensajes	Arquitectura basada en eventos, completamente desacoplada
Clean architecture	Mecanismo de separación clara de responsabilidades entre comandos y consultas
Idempotencia	Garantizar consistencia eventual y correcta sincronización de la base de datos
Atomicidad	Integridad en las transacciones, resiliente a fallos

Tácticas de Arquitectura asociadas al experimento	Descripción
Redis Streams	Mecanismo de propagación de eventos para mantener la consistencia eventual entre la tabla de escritura y la de lectura
CQRS	Separación clara entre comandos y consultas (y sus respectivas tablas) para evitar bloqueos en la base de datos
Deduplicación de eventos	Trackeo de eventos y su ejecución, con backpressure y reintentos
Unit of Work	Consistencia transaccional para mantener atomicidad, evitar inconsistencia enviando mensajes en transacciones fallidas y soportar rollback

Microservicio	Propósito y comportamiento esperado	Tecnología Asociada
Inventario	Gestiona el estado del inventario en tiempo real. Expone comandos para actualizar stock y consultas para verificar disponibilidad. Debe ser consistente y resiliente	Python (FastAPI), CQRS, PostgreSQL, Redis Streams
Redis Streams	Canal de eventos para desacoplar escritura y procesamiento. Garantiza orden, persistencia temporal y entrega confiable a múltiples consumidores	Redis Streams
Consumer	Procesa eventos del stream de forma asíncrona. Aplica lógica de negocio, actualiza proyecciones, y garantiza idempotencia y atomicidad en operaciones	Python async, asyncio, redis, PostgreSQL, Unit of Work

Conector	Comportamiento deseado en el experimento	Tecnología Asociada
Commands	Ejecuta múltiples comandos, realiza operaciones transaccionales UPDATE, INSERT, y publica eventos derivados en Redis Streams, con capacidad de rollback	Python async, UnitOfWork, aioredis, PostgreSQL
Queries	Expone consultas desacopladas sobre proyecciones optimizadas para lectura y ordenadas por criterios de negocio	FastAPI, PostgreSQL (vistas indexadas), async fetch
Event Publisher	Serializa y publica eventos resultantes de las transacciones en Redis Streams, asegurando trazabilidad, orden y persistencia temporal	UUID, Pydantic, aioredis, Redis Streams
Projection Reader	Expone consultas desacopladas sobre proyecciones como inventory_search, optimizadas para lectura y ordenadas por criterios de negocio	PostgreSQL (vistas indexadas), async fetch
Event Consumer	Consume eventos desde Redis Streams usando XREADGROUP y XAUTOCLAIM, actualiza proyecciones, maneja idempotencia, y registra eventos procesados	Python async, aioredis, PostgreSQL, Redis Streams
Retry Manager	Detecta errores en procesamiento, aplica reintentos con TTL, y redirige eventos fallidos a un Dead Letter Queue (DLQ) para análisis posterior	Redis (incr, expire), DLQ stream, logging
Heartbeat Monitor	Publica latidos periódicos para monitoreo de salud del consumidor, útil para dashboards y alertas	Redis (set con expiración), logging

Tecnología asociada con el experimento	Justificación
Python (async)	Permite construir flujos asíncronos eficientes para consumidores, emisores y APIs sin bloquear el event loop. Ideal para procesamiento paralelo
FastAPI	Es un framework ligero y rápido para construir APIs RESTful. Soporta tipado estático, documentación automática y excelente integración con async
Uvicorn	Es un ASGI ultrarrápido que ejecuta aplicaciones FastAPI. Compatible con async, ideal para entornos productivos y contenedores
Redis Streams	Backbone de eventos. Garantiza orden, persistencia temporal, entrega a múltiples consumidores y soporte para grupos de consumo y reclamos
aioredis	Cliente Redis asíncrono que permite interactuar con Streams, DLQ, heartbeats y reintentos sin bloquear el sistema
asyncpg	Driver PostgreSQL asíncrono de alto rendimiento. Ideal para operaciones concurrentes en consumidores y APIs
PostgreSQL	Base de datos relacional robusta. Soporta transacciones, proyecciones, deduplicación (ON CONFLICT), y trazabilidad de eventos
Patrón UnitOfWork	Encapsula transacciones para garantizar atomicidad entre operaciones relacionadas (UPDATE + INSERT + emit). Mejora claridad y testabilidad
Docker	Facilita el despliegue reproducible de microservicios, consumidores y Redis. Aísla entornos y simplifica CI/CD
Pydantic	Validación y serialización de datos estructurados. Asegura que los eventos publicados tengan formato consistente y seguro
Grafana k6	Simula tráfico realista y ayuda a medir el comportamiento del sistema bajo diferentes condiciones de carga

Integrante	Tareas a realizar	Esfuerzo Estimado
Andersen Castañeda	Crear las Tablas de la DB	1.5 horas
Andersen Castañeda	Crear los Modelos	1 hora
Andersen Castañeda	Crear el Diagrama de secuencia	1.5 horas
Andersen Castañeda	Crear la API de los comandos	3 horas
Andersen Castañeda	Crear la API de las consultas	1 horas
Andersen Castañeda	Crear las acciones para los eventos	1 hora
Andersen Castañeda	Crear los eventos en las transacciones	1 hora
Andersen Castañeda	Notificar eventos con idempotencia	3 hora
Andersen Castañeda	Aplicar patrón Unit of Work para consistencia	2 horas
Andersen Castañeda	Crear el consumer	1 hora
Andersen Castañeda	Soportar reintentos en el consumer	1 hora
Andersen Castañeda	Soportar TTL en el consumer	2 hora
Andersen Castañeda	Soportar DLQ y ACK en el consumer	2 hora
Andersen Castañeda	Soportar heartbeat en el consumer	1 hora
Andersen Castañeda	Implementar pruebas de carga con grafana k6	2 horas

Código Fuente

Enlace

Primeros Resultados

Pruebas de Lectura

Pruebas de Escritura y Lectura (Sincronización)

Análisis de Resultados

Todavía en proceso, el primer avance de esta semana se basó en construir el servicio para poder probarlo y unas pequeñas pruebas iniciales.

Diseño del experimento 2 de arquitectura

Seguridad de acceso (JWT + RBAC + Refresh + Revocación)

Título del experimento	Disponibilidad bajo carga
Propósito del experimento	Demostrar que solo tokens válidos, no revocados y con rol adecuado acceden a endpoints sensibles, con manejo correcto de expiración y refresh.
Hipótesis	Demostrar que solo tokens válidos, no revocados y con rol adecuado acceden a endpoints sensibles, con manejo correcto de expiración y refresh. Implementando RS256 con kid (rotación), roles en claims, blacklist por jti, y refresh separado, la tasa de accesos indebidos cae a 0% en pruebas y la validación añade < 5 ms p95.
Resultados esperados	100% de bloqueos correctos (401/403) en casos negativos.
	p95 de validación JWT < 5 ms; p99 < 8 ms.
	Rotación de claves sin indisponibilidad (gracia ≤ 60 s).
	Sin fuga de secretos (no se loguean claves ni tokens completos).
	Auditoría completa de intentos (éxito/fallo).
Recursos requeridos	Python + FastAPI, Uvicorn
	PyJWT (o equivalente) RS256, bcrypt
	Redis (para blacklist) o tabla SQL de respaldo
	pytest + httpx (tests), Postman/Swagger (demo)
	Docker (opcional para reproducibilidad)
Elementos de arquitectura involucrados	Autenticación (emisión de tokens), Autorización (RBAC por roles/scopes), Middleware de validación, Auditoría mínima.
Puntos de sensibilidad a probar	Validación criptográfica RS256 por kid, expiración con clock skew, revocación por jti, verificación de roles/scopes, latencia del middleware.
Esfuerzo estimado	24 horas.

Casos a probar

Caso	Descripción
Login OK	/auth/login → access_token (exp=15m), refresh_token.
Acceso con rol	GET /users/{id} con role=admin → 200.
Rol insuficiente	role=user → 403.
Token expirado	401
Token firma inválida	(clave equivocada) → 401.
Token revocado (jti en blacklist)	401
Refresh OK	/auth/refresh → nuevo access válido.
Refresh inválido/expirado	400/401.
Clock skew ±60 s	tolerancia configurable.

Código fuente

Enlace

Refinamiento estrategia de pruebas

Aplicación Bajo Pruebas

• Nombre Aplicación: MedySupply
• Versión: 1.0
• Entorno Web y móvil : (React, Flutter, Python, PostgreSQL).

Descripción

La Plataforma MediSupply, disponible en versión web y móvil, está diseñada para soportar de manera integral los procesos de compras, inventarios, logística, ventas y gestión de clientes dentro de un entorno de alta disponibilidad (7x24x365), con tiempos de respuesta ágiles (≤ 2 segundos en operaciones críticas), altos estándares de seguridad y la capacidad de evolucionar tecnológicamente conforme a las necesidades del negocio.

Actualmente, MediSupply enfrenta retos importantes en la administración de su cadena de suministro médico, tales como la falta de integración entre inventarios y la demanda proyectada, pérdidas recurrentes por vencimiento de productos y la desconexión entre las áreas de ventas, compras y logística. Estas limitaciones impactan directamente en la eficiencia operativa, incrementan los costos y ponen en riesgo el cumplimiento de los objetivos estratégicos de la compañía.

Funcionalidades Core

• Compras:

  • Registro de proveedores y productos.
  • Optimización de compras mediante algoritmos.
  • Gestión de certificaciones sanitarias y condiciones tributarias.

• Inventarios:

  • Consulta en tiempo real de inventario.
  • Gestión de lotes y fechas de vencimiento.
  • Alertas automáticas para productos próximos a vencer.

• Logística:

  • Generación de rutas óptimas para entregas.
  • Seguimiento en tiempo real de envíos.
  • Validación de cadena de frío.

• Ventas:

  • Creación y seguimiento de pedidos.
  • Recomendaciones de productos basadas en datos históricos.
  • Gestión de clientes institucionales.

• Gestión de Clientes:

  • Registro y autenticación de clientes.
  • Historial de pedidos y preferencias.
  • Notificaciones y alertas personalizadas.

Diagramas

Diagrama de Contexto

Diagrama de Arquitectura

Modelo de Datos

Contexto de la estrategia de pruebas

Objetivos

ID	Objetivo
OB1	Validar que el sistema maneje 400 usuarios concurrentes sin degradar el rendimiento (tiempo de respuesta ≤ 2 segundos en el 99% de las transacciones).
OB2	Asegurar que el sistema procese 400 pedidos por minuto durante picos de demanda sin fallos.
OB3	Verificar que las alertas de cadena de frío se generen y envíen en menos de 2 segundos.
OB4	Garantizar que el sistema cumpla con los estándares de seguridad, incluyendo autenticación multifactor y cifrado de datos sensibles.
OB5	Validar la integración con sistemas externos (pagos, geolocalización, IoT) sin errores.
OB6	Asegurar que el sistema mantenga una disponibilidad de ≥99,95% durante el periodo de pruebas.
OB7	Confirmar que las rutas logísticas se generen en menos de 3 segundos para 200 vehículos concurrentes.
OB8	Verificar que el sistema permita la creación masiva de productos (10,000 productos/hora) sin errores.
OB9	Validar que el 100% de los endpoints/pantallas administrativas exijan permisos explícitos y que accesos sin permiso reciban 403 en el 100% de los casos, medido en la suite de pruebas de aceptación.
OB10	Validar que el 100% de los logs de auditoría sean inmutables y solo accesibles por usuarios con privilegios autorizados.

Duración de la iteración de pruebas:

• Fecha de inicio: 1/Octubre/2025
• Fecha de fin: 30/Noviembre/2025
• Horas planeadas: 90 horas (4 semanas, 12 horas/semana)

Presupuesto de pruebas

Concepto	Costo Total USD
Recursos Humanos	18000
Herramientas y Licencias	2700
Servicios Externos	3000
Total	23700

Recursos Humanos

Rol	Cantidad	Experiencia Relevante	Tiempo Disponible (horas/semana)
Líder de Pruebas	1	1 año en pruebas de software, experiencia en pruebas de rendimiento y seguridad.	80
Analista de Pruebas Funcionales	2	1 año en pruebas funcionales, experiencia en herramientas como Selenium y JIRA.	80
Analista de Pruebas de Rendimiento	1	1 año en pruebas de rendimiento, experiencia con JMeter y LoadRunner.	80
Analista de Seguridad	1	1 año en pruebas de seguridad, experiencia en OWASP ZAP y Burp Suite.	80

Recursos Computacionales

• Equipos de Desarrollo y Pruebas
  • Computadoras para Desarrollo y Pruebas:
    • Especificaciones:
      • Procesador: Intel Core i5 / AMD Ryzen 7 o superior.
      • Memoria RAM: 16 GB mínimo (32 GB recomendado para pruebas de rendimiento).
      • Almacenamiento: 512 GB SSD o superior.
      • Sistema Operativo: Windows 10 / macOS / Linux (Ubuntu 20.04 o superior).
    • Cantidad: 4 equipos (2 para desarrollo backend, 2 para desarrollo móvil, 2 para pruebas automatizadas).
  • Dispositivos Móviles para Pruebas:
    • Modelos: Dispositivos Android (Samsung Galaxy S22, Google Pixel 6) e iOS (iPhone 13, iPad Air).
    • Cantidad: 4 dispositivos (2 Android, 2 iOS).

Herramientas de Pruebas

• Frameworks para Pruebas:
  • Cypress: Para pruebas end-to-end en aplicaciones web.
  • Jest: Para pruebas unitarias y de integración en JavaScript (React).
  • Pytest: Para pruebas unitarias y de integración en Python (backend).
  • Flutter driver: Para pruebas de integración en aplicaciones móviles desarrolladas con Flutter.
• Herramientas de Rendimiento:
  • JMeter: Para pruebas de carga y estrés en APIs y servicios backend.
• Herramientas de Accesibilidad:
  • i18n: Para pruebas de internacionalización y accesibilidad en aplicaciones web y móviles.

Entorno de Desarrollo

• Lenguajes de Programación:
  • Python: Para el desarrollo del backend.
  • Dart: Para el desarrollo de aplicaciones móviles con Flutter.
  • Typescript: Para el desarrollo de aplicaciones front-end con React
• Control de Versiones:
  • Git: Para el control de versiones del código fuente.
  • GitHub Actions: Para la integración y despliegue continuo (CI/CD).

Infraestructura en la Nube

• Google Cloud Platform (GCP):
  Kubernetes: Para la orquestación de contenedores en entornos de producción y pruebas. Docker: Para la creación y gestión de contenedores de aplicaciones. PostgreSQL: Base de datos relacional para almacenar la información del sistema.

Frameworks de Desarrollo

• Web:
  • React: Framework para el desarrollo de la interfaz de usuario web.
  • React-i18next: Para la internacionalización de la aplicación web.
• Móvil:
  • Flutter: Framework para el desarrollo de aplicaciones móviles multiplataforma.
  • flutter_i18n: Para la internacionalización de la aplicación móvil.

Recursos Adicionales

• Herramientas de Colaboración:
  • Slack / Microsoft Teams: Para la comunicación del equipo.
  • Jira : Para la gestión de tareas y seguimiento de proyectos.

TNT (Técnicas, Niveles y Tipos) de pruebas:

Nivel	Tipo	Técnica	Objetivo (ID)
Pruebas Unitarias	Funcionales	Pruebas automatizadas con pytest	OB1, OB2
Pruebas de Integración	Funcionales	Pruebas de APIs con Postman	OB5
Pruebas de Sistema	Rendimiento	Pruebas de carga con JMeter	OB1, OB2
Pruebas de Sistema	Seguridad	Pruebas de penetración con OWASP ZAP	OB4, OB9
Pruebas de Sistema	Usabilidad	Pruebas con usuarios reales	OB6
Pruebas de Aceptación	Funcionales	Pruebas manuales con clientes	OB3, OB7
Pruebas de Regresión	Funcionales	Automatizadas con Cypress	OB8
Pruebas de Sistema	Seguridad / Auditoría	Validación de logs con scripts automáticos + revisión manual	OB10

Distribución de Esfuerzo

Actividad	Responsable	Fecha Inicio	Fecha Fin	Esfuerzo (horas)
Diseño de casos de prueba	Líder de Pruebas	01/10/2025	10/10/2025	20
Ejecución de pruebas unitarias	Analista Funcional 1	11/10/2025	20/10/2025	30
Pruebas de integración	Analista Funcional 2	21/10/2025	30/10/2025	25
Pruebas de rendimiento	Analista de Rendimiento	02/11/2025	11/11/2025	40
Pruebas de seguridad	Analista de Seguridad	12/11/2025	20/11/2025	30
Pruebas de usabilidad
Líder de Pruebas	21/11/2025	25/11/2025	20
Pruebas de aceptación con clientes	Analista Funcional 1	26/11/2025	30/11/2025	25

Las pruebas unitarias se ejecutan de manera cíclica durante los 3 sprints del proyecto. Aunque se asigna un bloque específico de tiempo en el cronograma para su ejecución inicial, estas pruebas se repiten e iteran en cada sprint durante el desarrollo de las historias de usuario para asegurar la calidad continua del código y validar que las nuevas funcionalidades implementadas se despliegan correctamente.

Historias de Usuario Detalladas

Enlace al Backlog en Jira

Tablero de trabajo

Seguimiendo del proyecto

Vídeo con evidencias

Enlace a VoiceThread