Hoja de trabajo - galoryzen/equipo8-pfinal GitHub Wiki

Objetivos de Negocio

  • Objetivo Financiero: Incrementar ingresos anuales en 25% durante los próximos 3 años, reduciendo costos operativos en un 15% a través de automatización y eficiencia, comenzando en $51.6 millones y alcanzando $100.7 millones en el año 3.
  • Objetivo Operacional: Reducir abandonos de carrito del 25-30% actual al 8-10%, mejorando experiencia de usuario y aumentando conversión.
  • Objetivo de Compliance y Riesgo: Alcanzar cumplimiento PCI-DSS 3.2.1, GDPR y normativas locales en cada país dentro de 12 meses.

Restricciones de Negocio

  1. Operación continua durante la transformación (migración gradual): El sistema actual debe seguir operando sin interrupciones mientras se construye el nuevo. No se puede "apagar" la plataforma para migrar; los ~18,000 reservas mensuales y los $4.3M de ingresos mensuales no pueden detenerse.

  2. Presupuesto limitado con demostración de viabilidad antes de inversión mayor: No hay carta blanca financiera. Se debe demostrar viabilidad técnica en semana 16 como condición para que la empresa apruebe inversión de riesgo. Se deben valorizar tecnologías open-source para minimizar costos.

  3. Equipo máximo de 4 personas en 16 semanas: Solo 4 personas para arquitectura (8 semanas) y desarrollo (8 semanas). Esto limita severamente el alcance de lo que se puede construir y obliga a priorizar funcionalidades críticas para el MVP.

  4. Cumplimiento regulatorio multi-país en 12 meses: La plataforma opera en 6 países (Colombia, Perú, Ecuador, México, Chile, Argentina) con clientes en Europa y Brasil. Debe cumplir PCI-DSS 3.2.1, GDPR, LGPD y normativas locales de cada país.

Restricciones de Tecnología

  1. Cloud-agnostic (portabilidad obligatoria): Aunque actualmente la infraestructura está en AWS (us-east-1), el nuevo sistema debe ser portable y no atarse a un solo proveedor cloud. Esto restringe el uso de servicios propietarios de AWS y obliga a usar tecnologías estándar/portables.

  2. Stack Tecnológico Establecido: La solución deberá utilizar microservicios construidos con Python, FastAPI. Un Frontend Web construido con Typescript + React y una aplicación móvil construida con React Native.

  3. Integración con 15+ proveedores de PMS: Cada uno de los ~1,200 hoteles usa un PMS diferente, cada uno con sus propias APIs y formatos de datos. El nuevo sistema debe integrarse en tiempo real vía webhooks con todos estos proveedores.

Requisitos de Calidad

  • Escalabilidad
    • Capacidad base: 100 usuarios concurrentes por país
    • Picos estacionales: hasta 600 usuarios concurrentes simultáneos (6 países = 3,600 usuario/min)
    • Transacciones por minuto: 150 TPM (base) → 800 TPM (pico)
    • Autoescalado horizontal: agregar nodos de procesamiento automáticamente ante carga
    • Proyección a 3 años: crecer de 1,200 a 2,500 propiedades (108% volumen)
  • Disponibilidad
    • Disponibilidad objetivo: ≥ 99.95% mensual (máximo 21.6 minutos downtime/mes)
    • Redundancia geográfica: replicación activo-activo en ≥ 2 regiones por continente
    • RTO (Recovery Time Objective): ≤ 15 minutos ante fallo total
    • RPO (Recovery Point Objective): ≤ 5 minutos (pérdida máxima de datos)
    • Zero-downtime deployment: cambios de código sin interrupciones
    • Health checks cada 10 segundos
  • Seguridad
    • Cumplimiento PCI-DSS 3.2.1: datos de tarjeta nunca en bases de datos propias (usar tokenización)
    • Encriptación de datos en tránsito: TLS 1.2+ para todas las comunicaciones
    • Encriptación de datos en reposo: AES-256 para información sensible (emails, teléfonos, historial)
    • Autenticación multifactor (MFA): obligatorio para acceso administrativo, opcional para usuarios finales
    • Control de acceso basado en roles (RBAC): definir permisos específicos por ro
    • Auditoría completa: registrar todos los cambios de datos sensibles con timestamp, usuario, IP
    • Detección de anomalías: alertas < 2 segundos en intentos de fraude, accesos inusuales
    • Protección contra ataques comunes: CSRF, XSS, SQL Injection, brute force
    • GDPR compliance: derecho al olvido, exportación de datos, consent management
    • LGPD compliance (Brasil): similar a GDPR, datos locales
  • Mantenibilidad
    • Arquitectura de microservicios: módulos independientes con APIs claras
    • Agregar nuevo proveedor de pago: ≤ 40 horas/hombre
    • Cambiar política de cancelación: ≤ 8 horas/hombre (modificar un servicio, no 5+)
    • Agregar nuevo canal de distribución (OTA): ≤ 60 horas/hombre
    • Cobertura de tests: ≥ 80% para servicios críticos
    • API contracts bien definidos: OpenAPI/Swagger, versionadas
    • Documentación técnica actualizada: arquitectura, flujos, decisiones (ADRs)
    • CI/CD pipeline: despliegues múltiples veces al día sin riesgo
    • Rollback automático si hay fallas en producción
  • Confiabilidad: Garantizar la correcta operación continua, con mecanismos de recuperación ante fallos
  • Usabilidad: Interfaz intuitiva y adaptable a distintos perfiles de usuario.

Backlog de Arquitectura

El backlog lo podremos encontrar en Jira. Donde están las Historias de Arquitecturas asociadas a una épica. Ver Tablero Jira