Visión de arquitectura - galoryzen/equipo8-pfinal GitHub Wiki

Problema de negocio

TravelHub es una plataforma de reservas hoteleras con presencia en 6 países de Latinoamérica que enfrenta una crisis de escalabilidad, confiabilidad y seguridad en su sistema actual, lo que está causando:

  • Pérdida directa de ingresos: ~USD $300,000 anuales por abandono de carrito (25-30%) debido a tiempos de respuesta lentos (3-5 segundos vs. <1 segundo de la competencia).
  • Incapacidad de escalar: La arquitectura monolítica, diseñada hace 5 años para 50 reservas/min, no soporta la demanda actual (150-200 promedio, picos de 400). En temporadas altas se rechazan 35-40% de peticiones.
  • Riesgo de seguridad y cumplimiento: Datos de tarjeta almacenados en texto plano, incumplimiento de PCI-DSS 3.2.1, GDPR y LGPD. Pérdidas por fraude de ~USD $180,000 anuales.
  • Fragmentación operacional: Integraciones manuales con PMS causan overbooking, 50-80 tickets diarios por inconsistencias, y tiempos de resolución de 4-8 horas.
  • Deuda técnica paralizante: Código frágil e interdependiente, cobertura de tests <40%, agregar un proveedor de pago toma 6-8 semanas. Infraestructura en una sola región AWS sin plan de recuperación adecuado (RTO >4 horas).

La plataforma actual es insostenible para el crecimiento proyectado (30% anual) y requiere una transformación digital completa hacia una arquitectura moderna, distribuida y segura.

Objetivos de los StakeHolders

Laura Fernandez - Gerente de Producto y Crecimiento

  • Reducir abandono de carrito del 25-30% al 8-10%, mejorando tiempos de búsqueda a <1 segundo (competir con Booking/Airbnb).
  • Acelerar la capacidad de innovación: que agregar un nuevo proveedor de pago (ej. PayPal Argentina) no tome 6-8 semanas sino días. Necesita agilidad para responder al mercado.

Maria Gonzalez - Directora General

  • Recuperar ~USD $300,000 anuales perdidos por abandono de carrito.
  • Incrementar ingresos anuales en 25% durante los próximos 3 años (de $51.6M a $100.7M).
  • Reducir costos operativos en 15% a través de automatización y eficiencia.

Roberto Diaz - Responsable de Infraestructura y DevOps

  • Eliminar las caídas en temporadas altas (Semana Santa, Navidad) donde la BD llega a 85% CPU y se rechazan 35-40% de peticiones.
  • Lograr despliegues sin downtime (actualmente requieren 2-4 horas de parada).
  • Implementar redundancia geográfica (actualmente todo en AWS us-east-1, sin backups geo-distribuidos, RTO >4 horas).

Carlos Mendoza - VP de Tecnologia y Operaciones

  • Modernizar la arquitectura para soportar 150-200 reservas/min (promedio) y picos de 400+, en lugar de las 50/min del diseño original.
  • Reducir la fragilidad del código: un cambio en un país no debe romper funcionalidad en otro. Necesita componentes desacoplados.
  • Reducir pérdidas por fraude (~USD $180,000 anuales) y el 12% de falsas declinaciones en transacciones legítimas.

Miguel Torres - Gerente de Hoteles Partners

  • Sincronización en tiempo real con los PMS de los 1,200 hoteles asociados (actualmente cada 2-3 horas, causando overbooking).
  • Eliminar la sobreventa que daña la relación con los hoteles partners y fuerza rechazos de reservas.

Sandra Lopez - Servicio al Cliente

  • Automatizar la resolución de cambios y cancelaciones: actualmente 50-80 tickets diarios por inconsistencias con resolución manual de 4-8 horas.
  • Eliminar el 15% de cancelaciones rechazadas incorrectamente por inconsistencias de datos.

Javier Rios - Responsable de Cumplimiento y Seguridad

  • Alcanzar cumplimiento PCI-DSS 3.2.1 (datos de tarjeta en texto plano actualmente).
  • Cumplir con GDPR y LGPD para clientes en Europa y Brasil.
  • Mitigar riesgos de seguridad: ha habido 3 incidentes en 18 meses (robo de credenciales, ataque man-in-the-middle). Necesita encriptación end-to-end y tokenización.

Riesgos

  • Existencia de documentación incompleta o desactualizada del sistema actual, lo que puede dificultar la comprensión de la lógica de negocio.

  • Alta complejidad asociada a la migración gradual y a la operación simultánea de ambos sistemas (dual run).

  • Sobrecarga técnica para un equipo reducido al abordar una arquitectura distribuida, multirregión y con altos requisitos de seguridad.

  • Riesgo de sobreingeniería del MVP al diseñar desde el inicio para escenarios de alta escalabilidad y disponibilidad.

  • Dependencia de múltiples proveedores externos (PMS y pasarelas de pago), lo que introduce riesgos de integración y disponibilidad.

  • Riesgos de seguridad y de cumplimiento regulatorio asociados a la tokenización de datos y a la correcta implementación de GDPR, con potencial impacto legal elevado.

  • Resistencia al cambio organizacional frente a nuevos procesos, tecnologías y formas de operación.

  • Subestimación del esfuerzo requerido para implementar pruebas automatizadas, monitoreo y observabilidad en una arquitectura de microservicios.

Restricciones de Negocio y Tecnología

  • El equipo de desarrollo contará con un máximo de cuatro personas.

  • Se dispone de un período máximo de 16 semanas para la implementación de un MVP (8 semanas para arquitectura y 8 para desarrollo).

  • El estilo arquitectónico debe basarse en microservicios.

  • La arquitectura debe ser multirregión.

  • La arquitectura debe ser agnóstica al proveedor de nube.

  • Se deben priorizar tecnologías open source para minimizar los costos de licenciamiento.

  • El sistema legado debe continuar operando durante la transformación, lo que implica una migración gradual y la necesidad de integraciones temporales.

  • La arquitectura debe cumplir con PCI-DSS, GDPR y normativas locales, lo que restringe las opciones de diseño en almacenamiento, logging y manejo de datos sensibles.

Esfuerzo estimado

  • Fase de Arquitectura (8 semanas, 4 personas): 32 persona-semanas, dedicadas a la definición de la arquitectura de microservicios, elaboración de modelos (contexto, dominio, componentes y despliegue), decisiones arquitectónicas (ADRs), definición de contratos de APIs, diseño de seguridad (PCI-DSS, GDPR) y definición de la estrategia de despliegue multirregión y cloud-agnostic.

  • Fase de Desarrollo (8 semanas, 4 personas): 32 persona-semanas, dedicadas a la implementación de un MVP funcional, incluyendo búsqueda, reservas, pagos desacoplados, integración básica con PMS, autenticación, CI/CD, observabilidad mínima y despliegue multirregión.

Esfuerzo total estimado: 64 persona-semanas.

Modelo de Contexto

Modelo de Dominio

Link Modelo

Modelo de Componentes

Link Modelo

Modelo de Despliegue

Link Modelo