Lecciones aprendidas - galoryzen/equipo8-pfinal GitHub Wiki
1. Introducción
El Proyecto Final I tuvo como propósito diseñar y validar una arquitectura para TravelHub, una plataforma de reservas hoteleras con exigencias de rendimiento, escalabilidad, disponibilidad y seguridad. A lo largo de ocho semanas, el equipo desarrolló artefactos progresivos de análisis, diseño, experimentación, prototipado y planificación.
Este documento sintetiza los principales aprendizajes obtenidos, tanto técnicos como de proceso, y cómo preparan la continuidad hacia Proyecto Final II.
2. Lecciones aprendidas
2.1 Alineación temprana del equipo (Semana 1)
Definir acuerdos de trabajo, herramientas y objetivos desde el inicio redujo ambigüedad y reprocesos en fases posteriores. Los entregables administrativos (acta, tablero, acuerdos) impactan directamente la calidad técnica del proyecto.
2.2 Diseñar la arquitectura a profundidad ahorra trabajo futuro (Semana 2)
Dedicar tiempo a diseñar la arquitectura en detalle desde esta etapa nos ahorró trabajo significativo en semanas posteriores. Al tener claro desde el inicio cómo lo haríamos, los ajustes en fases siguientes fueron mínimos.
2.3 Diseñar buenos experimentos fue clave (Semanas 4-5)
Diseñar experimentos bien formulados fue lo más valioso de esta fase. Nos permitió salir de dudas sobre aspectos que no teníamos claros, obligándonos a definir qué atributo se validaba, qué métrica se observaría y cómo se interpretaría el resultado. El Experimento 1 (búsqueda con cache-aside Redis) y el Experimento 2 (reserva con concurrencia pesimista) demostraron que lecturas intensivas y escrituras transaccionales presentan riesgos distintos y exigen tácticas diferentes.
2.4 Validar la tecnología y la arquitectura con evidencia real (Semanas 6-7)
Aprovechamos estas semanas no solo para ejecutar los experimentos, sino también para utilizar las tecnologías que planeábamos usar en desarrollo y verificar que todo funcionara según lo esperado: Terraform, AWS, CloudMap, ECS y ElastiCache. Esto nos dio confianza en el stack tecnológico antes de entrar a la fase de implementación.
Realizar pruebas significativas que realmente nos permitieran conocer a fondo el comportamiento de nuestra arquitectura fue igualmente clave. El Experimento 2 mostró que la comunicación síncrona Booking→Catalog con SELECT FOR UPDATE y timeout de 500 ms cumplía el SLA incluso bajo alta contención (p95 en 260 ms vs. límite de 1.5 s). Al mismo tiempo, los percentiles altos y los errores 504 bajo 100 usuarios concurrentes revelaron que la degradación se concentra en la cola de latencia, algo que solo se hace visible cuando se miran percentiles altos y distribución de fallas, no solo promedios.
2.5 Consolidar da claridad para la fase de desarrollo (Semana 8)
Consolidar todo el trabajo de estas ocho semanas nos da un panorama claro y listo para entrar en la fase de desarrollo sin ningún pendiente. El cierre no fue solo compilar documentos, sino construir una narrativa coherente entre problema, backlog, arquitectura, experimentos, prototipos y plan de continuidad.
3. Conclusiones
Construir la arquitectura de TravelHub fue un desafío retador pero muy enriquecedor. A medida que avanzábamos en el diseño surgían constantemente preguntas que nos llevaban a investigar, probar y profundizar en temas que no conocíamos. Ese ciclo de duda, investigación y resolución fue probablemente donde más aprendimos como equipo.
Terminamos Proyecto Final I con satisfacción por el trabajo entregado y con confianza en que tenemos una base sólida para ejecutar el plan de desarrollo en Proyecto Final II. La arquitectura está diseñada, validada con experimentos, y el backlog está refinado y organizado por sprints. Estamos listos para construir.