Escenarios de Calidad

Escenarios Disponibilidad

Escenario A1.1: Falla en Microservicio de Búsqueda durante Temporada Alta

Elemento	Descripción
Fuente de Estímulo	Equipo de desarrollo
Estímulo	Despliegue de nuevo código en el microservicio de búsqueda causa fallo en uno de los contenedores
Artefacto	Microservicio de búsqueda de hospedaje de TravelHub
Ambiente	Operación normal en temporada alta (Semana Santa) con 600 usuarios concurrentes por país (3,600 usuarios/min total)
Respuesta	El sistema detecta el fallo del contenedor, lo retira automáticamente del pool de servicios y lanza una nueva instancia saludable. El balanceador de carga redirige el tráfico a las instancias disponibles sin interrupción del servicio.
Medida de Respuesta	Tiempo de restauración ≤ 3 minutos; pérdida de solicitudes ≤ 0.1% durante la transición; disponibilidad mensual ≥ 99.95%
Validación ASR	Prueba de inyección de fallas demuestra que ante un despliegue erróneo en temporada alta, el sistema reemplaza el contenedor defectuoso en ≤ 3 min y mantiene disponibilidad ≥ 99.95% mensual

Escenario A1.2: Fallo Total de Región de AWS

Elemento	Descripción
Fuente de Estímulo	Proveedor de infraestructura (AWS)
Estímulo	Falla completa de la región us-east-1 donde opera el sistema principal
Artefacto	Plataforma completa TravelHub (web + móvil + API + bases de datos)
Ambiente	Operación normal con 150 TPM (transacciones por minuto)
Respuesta	El sistema de monitoreo detecta la caída de la región primaria y activa automáticamente el failover a la región secundaria (us-west-2). El tráfico se redirige mediante Route 53 a los recursos de la región de respaldo.
Medida de Respuesta	RTO (Recovery Time Objective) ≤ 15 minutos; RPO (Recovery Point Objective) ≤ 5 minutos; detección del fallo ≤ 30 segundos
Validación ASR	Simulación de fallo regional demuestra failover automático en ≤ 15 min con pérdida de datos ≤ 5 min

Escenario A1.3: Despliegue con Zero-Downtime

Elemento	Descripción
Fuente de Estímulo	Equipo DevOps
Estímulo	Despliegue de nueva versión del microservicio de pagos durante horario de operación
Artefacto	Microservicio de procesamiento de pagos
Ambiente	Operación normal con 800 TPM en temporada alta (7:00-9:00 PM)
Respuesta	El sistema ejecuta despliegue blue-green: la nueva versión se despliega en paralelo y recibe 5% del tráfico. Si las métricas son exitosas después de 10 minutos, el tráfico se incrementa gradualmente hasta 100%. Si hay errores, se revierte automáticamente a la versión anterior.
Medida de Respuesta	Zero downtime durante el despliegue; tiempo de rollback automático ≤ 2 minutos si se detectan errores; health checks cada 10 segundos
Validación ASR	Pruebas de despliegue demuestran cero interrupciones y rollback automático funcional en ≤ 2 min ante fallos

Escenarios Desempeño

Escenario A2.1: Búsqueda de Hospedaje en Condiciones Normales

Elemento	Descripción
Fuente de Estímulo	Usuario final (viajero)
Estímulo	Búsqueda de hospedaje con filtros: ciudad, fechas, capacidad, rango de precio
Artefacto	Motor de búsqueda de hospedaje (portal web)
Ambiente	Operación normal, 100 usuarios concurrentes por país, base de datos con 1,200 propiedades y 8,000-12,000 SKUs de habitaciones
Respuesta	El sistema procesa la consulta aplicando filtros, consulta caché distribuido y bases de datos replicadas, y devuelve resultados ordenados por relevancia
Medida de Respuesta	P95 ≤ 800ms para la entrega de resultados (mejora de 3-5s actuales); tasa de abandono de carrito reducida de 25-30% a 8-10%
Validación ASR	Test de carga automatizado confirma P95 ≤ 800ms en búsquedas con múltiples filtros bajo carga normal

Escenario A2.2: Consulta de Histórico de Reservas

Elemento	Descripción
Fuente de Estímulo	Usuario autenticado (viajero)
Estímulo	Consulta del histórico completo de reservas desde el portal web
Artefacto	Módulo de gestión de reservas (portal web)
Ambiente	Operación normal, usuario con 20-30 reservas históricas
Respuesta	El sistema recupera el historial desde base de datos optimizada con índices, aplicando paginación y cache para resultados frecuentes
Medida de Respuesta	P95 ≤ 1 segundo para cargar histórico (mejora de 6-8s actuales); desviación estándar ≤ 0.3s
Validación ASR	Pruebas de rendimiento confirman P95 ≤ 1s en consultas de histórico con 100 usuarios concurrentes

Escenario A2.3: Procesamiento de Pago

Elemento	Descripción
Fuente de Estímulo	Usuario final completando reserva
Estímulo	Procesamiento de pago con proveedor externo (Stripe, MercadoPago, etc.)
Artefacto	Microservicio de procesamiento de pagos
Ambiente	Operación normal, 150 TPM (base)
Respuesta	El sistema tokeniza los datos de tarjeta, invoca API del proveedor de pago asíncronamente, registra la transacción y actualiza el estado de la reserva
Medida de Respuesta	P95 ≤ 3 segundos para completar transacción (mejora de 4-6s actuales); tasa de falsas declinaciones reducida de 12% a < 5%
Validación ASR	Métricas de APM confirman P95 ≤ 3s bajo carga de 150 TPM con múltiples proveedores de pago

Escenario A2.4: Consulta de Disponibilidad en Tiempo Real

Elemento	Descripción
Fuente de Estímulo	Usuario final (viajero o agencia)
Estímulo	Consulta de disponibilidad de habitación específica para fechas seleccionadas
Artefacto	Microservicio de inventario hotelero
Ambiente	Operación normal con sincronización de 1,200 propiedades hoteleras
Respuesta	El sistema consulta caché distribuido actualizado cada 5 minutos, valida disponibilidad con PMS del hotel si es necesario, y devuelve estado actualizado
Medida de Respuesta	P99 ≤ 200ms para respuesta de disponibilidad; sincronización de inventario cada 5 minutos (mejora de 2-3 veces por día)
Validación ASR	Test de integración confirma P99 ≤ 200ms y reducción de overbooking a < 2%

Escenarios Escalabilidad

Escenario A3.1: Pico de Demanda en Temporada Alta (Semana Santa)

Elemento	Descripción
Fuente de Estímulo	Usuarios finales en 6 países durante temporada alta
Estímulo	Incremento abrupto de carga de 150 TPM a 800 TPM en horario pico (7:00-9:00 PM)
Artefacto	Sistema completo de TravelHub (búsqueda, reservas, pagos)
Ambiente	Operación en temporada alta con hasta 600 usuarios concurrentes por país (3,600 usuarios/min total)
Respuesta	El sistema escala automáticamente la capacidad de cómputo mediante autoescalado horizontal (agregar nodos de procesamiento), incrementa réplicas de bases de datos de lectura y amplía capacidad de caché distribuido
Medida de Respuesta	El sistema pasa de procesar 150 TPM a 800 TPM en ≤ 5 minutos; tasa de rechazo de peticiones < 1% (mejora de 35-40% actual); CPU de base de datos ≤ 75% durante picos
Validación ASR	Prueba de carga demuestra escalado automático de 150→800 TPM en ≤ 5 minutos manteniendo latencias objetivo

Escenario A3.2: Crecimiento Proyectado a 3 Años

Elemento	Descripción
Fuente de Estímulo	Crecimiento del negocio (nuevos hoteles y clientes)
Estímulo	Incremento de inventario de 1,200 a 2,500 propiedades hoteleras (108% de volumen)
Artefacto	Sistema completo de TravelHub (inventario, búsqueda, reservas)
Ambiente	Operación normal con crecimiento gradual del 30% anual
Respuesta	La arquitectura de microservicios permite escalar componentes independientemente. Bases de datos se fragmentan (sharding) por región geográfica. Caché distribuido maneja incremento de SKUs (8,000→17,000 habitaciones).
Medida de Respuesta	El sistema soporta el crecimiento sin degradación de latencias objetivo; capacidad para procesar 2,500 propiedades manteniendo P95 ≤ 800ms en búsquedas
Validación ASR	Pruebas de estrés con datos sintéticos de 2,500 propiedades confirman cumplimiento de latencias y capacidad de procesamiento

Escenario A3.3: Integración de Nuevos PMS (Property Management Systems)

Elemento	Descripción
Fuente de Estímulo	Área de Partnerships (nuevos hoteles con diferentes PMS)
Estímulo	Incorporación de 200 nuevos hoteles que usan 5 nuevos proveedores de PMS no integrados
Artefacto	Sistema de integración de inventario hotelero
Ambiente	Operación normal con 1,200 propiedades actuales usando 15+ proveedores de PMS
Respuesta	El sistema usa arquitectura de adaptadores (patrón Adapter). Cada nuevo PMS requiere desarrollar un adaptador específico que cumple con la interfaz estándar de integración.
Medida de Respuesta	Tiempo de integración de nuevo proveedor de PMS ≤ 60 horas/hombre; sincronización de inventario cada 5 minutos sin degradación de rendimiento
Validación ASR	Desarrollo e integración de adaptador de prueba demuestra tiempo ≤ 60 horas y funcionamiento estable

Escenarios Seguridad

Escenario A4.1: Intento de Acceso No Autorizado a Datos de Tarjeta

Elemento	Descripción
Fuente de Estímulo	Atacante externo
Estímulo	Intento de acceso directo a base de datos para extraer información de tarjetas de crédito
Artefacto	Sistema de procesamiento de pagos y base de datos
Ambiente	Operación normal con cumplimiento PCI-DSS 3.2.1
Respuesta	Los datos de tarjeta nunca se almacenan en bases de datos propias (tokenización mediante proveedores como Stripe). El sistema detecta el intento de acceso no autorizado, registra la actividad en logs de auditoría y genera alerta en el SIEM.
Medida de Respuesta	0% de datos de tarjeta almacenados en texto plano; detección de anomalía y generación de alerta < 2 segundos; 100% cumplimiento PCI-DSS 3.2.1
Validación ASR	Auditoría de seguridad y pruebas de penetración confirman cumplimiento PCI-DSS y tokenización efectiva

Escenario A4.2: Detección de Fraude en Tiempo Real

Elemento	Descripción
Fuente de Estímulo	Usuario malintencionado
Estímulo	Intento de reserva con tarjeta clonada o patrones de uso fraudulento (múltiples transacciones en corto tiempo, ubicaciones geográficas imposibles)
Artefacto	Sistema de detección de fraude
Ambiente	Operación normal procesando 150-800 TPM
Respuesta	El sistema analiza en tiempo real patrones de comportamiento usando reglas de negocio y machine learning. Detecta anomalías como: acceso desde China hace 5 minutos y ahora desde Argentina, múltiples reservas con diferentes tarjetas en < 1 minuto, etc. Bloquea la transacción y genera alerta.
Medida de Respuesta	Detección de fraude y generación de alerta < 2 segundos; reducción de pérdidas por fraude de $180,000/año a < $50,000/año; tasa de falsos positivos < 3%
Validación ASR	Pruebas con casos de fraude sintético demuestran detección < 2s y precisión ≥ 97%

Escenario A4.3: Ataque Man-in-the-Middle en Transmisión de Datos

Elemento	Descripción
Fuente de Estímulo	Atacante interceptando comunicaciones
Estímulo	Intento de intercepción de datos de tarjeta durante transmisión entre cliente y servidor
Artefacto	Capa de comunicación web y móvil
Ambiente	Operación normal con usuarios en redes públicas
Respuesta	Todas las comunicaciones están protegidas con TLS 1.2+ (encriptación end-to-end). Los datos de tarjeta se tokenizan en el cliente antes de transmitirse. El atacante solo intercepta datos encriptados inútiles.
Medida de Respuesta	100% de comunicaciones cifradas con TLS 1.2+; 0% de datos sensibles transmitidos en texto plano; certificados SSL/TLS renovados automáticamente
Validación ASR	Análisis de tráfico de red y pruebas de penetración confirman encriptación efectiva en todas las capas

Escenario A4.4: Acceso No Autorizado por Credenciales Comprometidas

Elemento	Descripción
Fuente de Estímulo	Atacante con credenciales robadas de empleado administrativo
Estímulo	Intento de acceso al panel administrativo con credenciales legítimas pero desde ubicación inusual
Artefacto	Sistema de autenticación y control de acceso
Ambiente	Operación normal con empleados en 6 países
Respuesta	El sistema requiere autenticación multifactor (MFA) para todos los accesos administrativos. Detecta anomalías de ubicación (empleado de Colombia accediendo desde Rusia) y requiere verificación adicional. Implementa RBAC: empleado de Colombia no puede ver datos de clientes de Argentina.
Medida de Respuesta	100% de accesos administrativos con MFA; detección de anomalía y solicitud de verificación adicional < 2 segundos; control de acceso basado en roles (RBAC) aplicado en 100% de operaciones
Validación ASR	Pruebas de acceso con credenciales comprometidas demuestran bloqueo efectivo y requerimiento de MFA

Escenario A4.5: Cumplimiento con GDPR y LGPD

Elemento	Descripción
Fuente de Estímulo	Usuario final en Europa o Brasil
Estímulo	Solicitud de ejercer derecho al olvido (eliminación de datos personales) según GDPR/LGPD
Artefacto	Sistema de gestión de datos personales
Ambiente	Operación normal con usuarios en múltiples jurisdicciones
Respuesta	El sistema tiene implementado un módulo de gestión de consentimiento y privacidad. Ante la solicitud, identifica todos los datos personales del usuario en todas las bases de datos y sistemas, los anonimiza o elimina según la regulación, y genera certificado de cumplimiento.
Medida de Respuesta	Tiempo de procesamiento de solicitud de derecho al olvido ≤ 72 horas; 100% de datos personales identificados y eliminados/anonimizados; auditoría completa con trazabilidad
Validación ASR	Auditoría de cumplimiento GDPR/LGPD confirma implementación correcta de derechos de privacidad

Escenarios Usabilidad

Escenario A5.1: Cancelación de Reserva por Usuario Final

Elemento	Descripción
Fuente de Estímulo	Usuario final (viajero)
Estímulo	Decide cancelar una reserva confirmada desde el portal web o móvil
Artefacto	Interfaz de gestión de reservas (web y móvil)
Ambiente	Operación normal
Respuesta	El sistema valida las políticas de cancelación aplicables, calcula el reembolso automáticamente, muestra información clara al usuario y procesa la devolución. Envía confirmación por email y notificación push (móvil).
Medida de Respuesta	La cancelación se completa en ≤ 3 segundos; el usuario recibe confirmación visual inmediata y feedback claro sobre monto de reembolso; reducción de cancelaciones rechazadas incorrectamente de 15% a < 2%
Validación ASR	Pruebas de usabilidad muestran que ≥ 95% de usuarios logran cancelar una reserva en el primer intento sin confusión

Escenario A5.2: Modificación de Fechas de Reserva

Elemento	Descripción
Fuente de Estímulo	Usuario final o agencia de viajes
Estímulo	Solicita cambio de fechas de una reserva existente
Artefacto	Módulo de gestión de reservas (web/móvil)
Ambiente	Operación normal con 50-80 tickets diarios de modificaciones
Respuesta	El sistema consulta disponibilidad en las nuevas fechas, calcula diferencia de tarifa, muestra opciones al usuario y procesa el cambio automáticamente sin intervención manual del equipo de servicio al cliente.
Medida de Respuesta	Tiempo de modificación ≤ 2 minutos (mejora de 4-8 horas actuales); 100% de modificaciones procesadas automáticamente sin necesidad de llamadas telefónicas; feedback claro en cada paso del proceso
Validación ASR	Pruebas con usuarios confirman que ≥ 90% completan modificaciones sin contactar servicio al cliente

Escenario A5.3: Búsqueda con Filtros Avanzados

Elemento	Descripción
Fuente de Estímulo	Usuario final (viajero)
Estímulo	Aplica múltiples filtros en búsqueda (ubicación, precio, amenidades, calificación) y refina resultados
Artefacto	Interfaz de búsqueda (web y móvil)
Ambiente	Operación normal con catálogo de 1,200 propiedades
Respuesta	El sistema muestra resultados actualizados dinámicamente a medida que el usuario ajusta filtros, con indicadores visuales del número de resultados y feedback inmediato sin recargar la página completa
Medida de Respuesta	Actualización de resultados al cambiar filtros ≤ 500ms; 100% de filtros con contadores de resultados visibles; indicadores de carga claros durante procesamiento
Validación ASR	Pruebas de usabilidad confirman que ≥ 85% de usuarios encuentran lo que buscan en menos de 3 refinamientos de búsqueda

Escenario A5.4: Visualización de Detalles de Propiedad

Elemento	Descripción
Fuente de Estímulo	Usuario final (viajero)
Estímulo	Selecciona una propiedad de los resultados de búsqueda para ver detalles completos
Artefacto	Página de detalle de propiedad (web y móvil)
Ambiente	Operación normal
Respuesta	El sistema carga y muestra imágenes, descripción, amenidades, ubicación en mapa, reseñas de usuarios y tarifas disponibles de forma progresiva (progressive loading)
Medida de Respuesta	P95 ≤ 500ms para carga de página de detalle (mejora de 1.2-1.5s actual); imágenes con lazy loading; contenido principal visible en < 300ms
Validación ASR	Métricas de Web Vitals confirman LCP (Largest Contentful Paint) ≤ 500ms en P95

Escenarios Mantenibilidad

Escenario A6.1: Agregar Nuevo Proveedor de Pago

Elemento	Descripción
Fuente de Estímulo	Gerente de Producto (Laura Fernández)
Estímulo	Solicitud de integración de PayPal Local para Argentina como nuevo medio de pago
Artefacto	Microservicio de procesamiento de pagos
Ambiente	Tiempo de diseño y desarrollo
Respuesta	El equipo técnico desarrolla un nuevo adaptador de pago que implementa la interfaz estándar definida. El adaptador encapsula la lógica específica de PayPal. No se modifican otros microservicios (búsqueda, reservas, inventario).
Medida de Respuesta	Tiempo de desarrollo e integración ≤ 40 horas/hombre (mejora de 6-8 semanas actuales); afecta solo 1 módulo; cobertura de tests ≥ 80%; despliegue sin downtime
Validación ASR	Registro de cambios y métricas de desarrollo confirman tiempo ≤ 40 horas y cero impacto en otros servicios

Escenario A6.2: Cambio de Política de Cancelación

Elemento	Descripción
Fuente de Estímulo	Área de Operaciones
Estímulo	Modificación de las reglas de reembolso para cancelaciones (nueva política: reembolso 100% si cancela 48h antes, 50% si cancela 24h antes, 0% después)
Artefacto	Microservicio de gestión de reservas
Ambiente	Tiempo de diseño (modificación de reglas de negocio)
Respuesta	Se modifica la configuración de políticas en el microservicio de reservas, se actualizan los tests unitarios e integración, se despliega con CI/CD pipeline
Medida de Respuesta	Tiempo de modificación y despliegue ≤ 8 horas/hombre; afecta solo el servicio de reservas (no pagos, búsqueda, etc.); tests automatizados validan la nueva lógica; rollback disponible
Validación ASR	Pruebas de regresión confirman que el cambio afecta solo 1 servicio y funciona correctamente en todos los escenarios

Escenario A6.3: Agregar Nuevo Canal de Distribución (OTA)

Elemento	Descripción
Fuente de Estímulo	Área de Partnerships
Estímulo	Integración con Expedia como nuevo canal de distribución (OTA - Online Travel Agency)
Artefacto	API pública de TravelHub y sistema de integración de canales
Ambiente	Tiempo de diseño y desarrollo
Respuesta	El equipo desarrolla un adaptador específico para el protocolo de Expedia que se conecta a la API pública estandarizada de TravelHub. La arquitectura orientada a servicios permite exponer inventario y reservas sin modificar la lógica core.
Medida de Respuesta	Tiempo de integración ≤ 60 horas/hombre; API contracts bien definidos en OpenAPI/Swagger versionados; documentación técnica actualizada; cobertura de tests ≥ 80%
Validación ASR	Integración exitosa con OTA de prueba en ≤ 60 horas sin modificar servicios core

Escenario A6.4: Onboarding de Nuevo Desarrollador

Elemento	Descripción
Fuente de Estímulo	Equipo de Recursos Humanos
Estímulo	Incorporación de nuevo desarrollador al equipo técnico
Artefacto	Documentación técnica, repositorio de código, arquitectura
Ambiente	Ambiente de desarrollo
Respuesta	El nuevo desarrollador accede a documentación actualizada (ADRs - Architecture Decision Records, diagramas C4, contratos de API), clona repositorio con README claro, ejecuta scripts de setup de ambiente local, y puede hacer su primer commit en tareas de baja complejidad
Medida de Respuesta	Tiempo para entender el sistema y hacer primer commit productivo ≤ 3 días (mejora de semanas actuales); documentación técnica actualizada en ≥ 90%; cobertura de código ≥ 80% facilita comprensión
Validación ASR	Encuestas a nuevos desarrolladores confirman comprensión del sistema en ≤ 3 días

Escenario A6.5: Despliegue Múltiple en un Día

Elemento	Descripción
Fuente de Estímulo	Equipo de desarrollo
Estímulo	Necesidad de hacer 3 despliegues en un día: hotfix crítico en la mañana, nueva feature al mediodía, optimización de rendimiento en la tarde
Artefacto	Pipeline de CI/CD completo
Ambiente	Operación normal de desarrollo ágil
Respuesta	El pipeline CI/CD ejecuta automáticamente: lint, tests unitarios, tests de integración, tests E2E, análisis de seguridad, build y deploy a staging. Si todos los gates están verdes, permite deploy a producción con blue-green o canary.
Medida de Respuesta	Pipeline completo ≤ 15 minutos por deploy; rollback automático si hay fallas en producción detectadas; múltiples deploys por día sin riesgo; zero downtime
Validación ASR	Métricas de CI/CD muestran tiempo promedio de pipeline < 15 min y capacidad para múltiples deploys diarios

Escenarios Interoperabilidad

Escenario A7.1: Sincronización con Múltiples PMS

Elemento	Descripción
Fuente de Estímulo	Sistemas PMS de hoteles (15+ proveedores diferentes)
Estímulo	Actualización de disponibilidad y tarifas desde sistemas heterogéneos
Artefacto	Sistema de integración de inventario hotelero
Ambiente	Operación normal sincronizando 1,200 propiedades con 8,000-12,000 SKUs
Respuesta	El sistema consume APIs de diferentes PMS usando adaptadores específicos por proveedor. Normaliza los datos a un formato estándar interno. Actualiza el inventario en caché distribuido y base de datos centralizada.
Medida de Respuesta	Frecuencia de sincronización cada 5 minutos (mejora de 2-3 veces por día); tasa de error en sincronización < 1%; tiempo de detección de inconsistencias < 10 minutos
Validación ASR	Pruebas de integración con PMS de prueba confirman sincronización cada 5 min y detección de errores efectiva

Escenario A7.2: Integración con Proveedores de Pago Internacionales

Elemento	Descripción
Fuente de Estímulo	Proveedores de pago (Stripe, MercadoPago, OpenPay, PayPal)
Estímulo	Procesamiento de transacción en 6 monedas diferentes (USD, ARS, CLP, PEN, COP, MXN)
Artefacto	Microservicio de procesamiento de pagos
Ambiente	Operación normal procesando 150-800 TPM
Respuesta	El sistema selecciona el proveedor de pago óptimo según país, moneda y disponibilidad. Invoca la API del proveedor de forma asíncrona, maneja respuestas exitosas y errores, implementa reintentos con exponential backoff, y registra todas las transacciones para auditoría.
Medida de Respuesta	Soporte para múltiples proveedores de pago sin acoplamiento; tiempo de integración de nuevo proveedor ≤ 40 horas; tasa de transacciones exitosas ≥ 95%; manejo de fallos con reintentos automáticos
Validación ASR	Pruebas de integración con sandbox de proveedores confirman funcionamiento correcto en múltiples monedas