Experimento 2 - galoryzen/equipo8-pfinal GitHub Wiki

Experimento 2
Título del experimento Validación de latencia en creación de reserva con comunicación síncrona Booking → Catalog bajo carga concurrente
Propósito del experimento Validar que la táctica de comunicación síncrona HTTP entre Booking Service y Catalog Service, con control de concurrencia pesimista (SELECT FOR UPDATE) en PostgreSQL, cumple el SLA de latencia p95 < 1.5s para la creación de reserva bajo carga pico.
Resultados esperados Determinar si la latencia p95 del endpoint POST /api/bookings/checkout-start se mantiene por debajo de 1.5s bajo los escenarios de carga definidos (normal, pico y alta contención), e identificar el umbral de concurrencia donde la táctica se quiebra, si existe.
Recursos requeridos AWS: 2 tareas ECS Fargate (Booking + Catalog), 1 ALB, 1 instancia RDS PostgreSQL, Cloud Map. Herramientas: Locust, CloudWatch.
Elementos de arquitectura involucrados Booking Service, Catalog Service, ALB, PostgreSQL (esquemas booking + catalog), Cloud Map (service discovery)
Esfuerzo estimado 21 horas / hombre 
sequenceDiagram
    participant LC as Generador de Carga
    participant ALB as ALB
    participant BOOK as Booking Service
    participant CAT as Catalog Service
    participant DB as PostgreSQL

    Note over LC: N usuarios concurrentes<br/>simulando checkout-start

    LC->>ALB: POST /api/bookings/checkout-start
    ALB->>BOOK: Enruta petición

    BOOK->>CAT: createHold(room_type, dates, 15min)
    Note over CAT,DB: Punto de sensibilidad:<br/>contención bajo carga

    CAT->>DB: SELECT FOR UPDATE en inventory_calendar
    Note over DB: Lock en filas del<br/>mismo room_type + fechas
    DB-->>CAT: Rows locked
    CAT->>DB: INSERT inventory_hold
    DB-->>CAT: Hold creado
    CAT-->>BOOK: HoldCreated (hold_id)

    BOOK->>DB: INSERT booking (estado CART)
    DB-->>BOOK: Booking creado
    BOOK-->>ALB: 201 booking_id
    ALB-->>LC: 201 booking_id

    Note over LC: Mide latencia end-to-end<br/>p50, p95, p99
Loading

Hipótesis de diseño
Punto de sensibilidad La llamada síncrona HTTP de Booking a Catalog para crear el inventory hold está en el camino crítico de la reserva. Catalog ejecuta un SELECT FOR UPDATE sobre las filas de inventario, lo cual genera locks a nivel de fila en PostgreSQL. Bajo alta concurrencia (muchos usuarios reservando el mismo room_type en las mismas fechas), estos locks se encolan y la latencia podría crecer de forma no lineal. No conocemos el umbral de concurrencia donde esto se convierte en problema.
Historia de Arquitectura asociada ASR-59: Creación de reserva en tiempo objetivo (< 1.5s p95)
Como viajero que confirma una reserva válida, cuando envío la solicitud en operación normal o pico, quiero que el sistema cree la reserva y responda. Esto debe suceder en menos de 1.5 s (p95), dejando el pago en proceso asíncrono, de modo que la experiencia sea fluida y no dependa de la latencia del proveedor de pago.
Nivel de incertidumbre Medio-Alto. En operación normal, la estimación teórica es baja. Sin embargo, bajo alta contención concurrente en las mismas filas de inventario, el comportamiento de los locks en PostgreSQL es no lineal y dependiente de la carga. No tenemos evidencia de cómo se comporta la cadena completa Booking → Catalog → PostgreSQL bajo carga pico real.

Estilos y Tácticas de arquitectura

Estilo (C&C) Análisis
Llamado-Retorno (Cliente-Servidor) Booking actúa como cliente y Catalog como servidor en la llamada síncrona createHold. El estilo favorece la latencia (Desempeño), que es nuestro atributo de calidad priorizado. Pero desfavorece la disponibilidad y facilidad de modificación
Llamado-Retorno (SOA) Booking y Catalog son microservicios independientes. El estilo favorece la modificabilidad y escalabilidad (cada servicio se despliega y escala por separado). Pero desfavorece el desempeño al introducir un salto de red adicional en el camino crítico, cuya latencia debe mantenerse dentro del SLA.
Táctica Análisis
Reducir el overhead La comunicación Booking → Catalog se resuelve vía Cloud Map DNS dentro de la VPC, sin salir a Internet. Esto minimiza la latencia de resolución de servicio (~1ms) y elimina overhead de red externa en el camino crítico.
Limitar tiempo de ejecución Se configura un timeout en la llamada HTTP de Booking a Catalog (ej: 500ms). Si Catalog no responde a tiempo, Booking falla rápido en lugar de quedarse esperando, evitando que un request lento degrade la latencia de los demás.
Introducir concurrencia FastAPI con async/await permite que tanto Booking como Catalog procesen múltiples requests de forma concurrente sin bloquear hilos. Esto es clave para que el throughput no se degrade cuando hay muchos requests simultáneos al endpoint de reserva.
Planificar el uso de los recursos Connection pooling a PostgreSQL (asyncpg) reutiliza conexiones existentes en lugar de crear una nueva por cada request. Evita el overhead de establecimiento de conexión y controla el número máximo de conexiones concurrentes a la BD.

Listado de componentes

Componente Propósito y comportamiento esperado Tecnología asociada
Booking Service Recibe la solicitud de checkout-start del usuario, llama a Catalog para crear el inventory hold, persiste la reserva en estado CART y retorna el booking_id. Es el endpoint bajo prueba. FastAPI (Python), ECS Fargate
Catalog Service Recibe la solicitud de createHold desde Booking, ejecuta la validación de inventario y creación de hold con lock pesimista en PostgreSQL. Es donde se espera la mayor presión bajo contención. FastAPI (Python), ECS Fargate
PostgreSQL Almacena el inventario (tabla inventory_calendar) y los holds. Ejecuta los SELECT FOR UPDATE + INSERT que generan contención bajo concurrencia. Instancia compartida con esquemas separados (catalog, booking). Amazon RDS PostgreSQL
Generador de carga Simula múltiples usuarios concurrentes haciendo requests a POST /api/bookings/checkout-start a través del ALB. Mide latencia end-to-end, throughput y tasa de error. Locust
ALB Punto de entrada que enruta las peticiones al Booking Service. Incluido para medir la latencia realista del camino completo. AWS Application Load Balancer

Conectores evaluados

Conector Comportamiento esperado en el conector Tecnología asociada
HTTP síncrono (ALB → Booking) Enruta peticiones del generador de carga al Booking Service. Se espera latencia baja. No debería ser cuello de botella. ALB + Target Group
HTTP síncrono (Booking → Catalog) Llamada interna de Booking a Catalog para createHold. Resuelta vía Cloud Map DNS dentro de la VPC. Es el conector bajo evaluación principal: su latencia depende del tiempo de procesamiento de Catalog + locks en PostgreSQL. httpx + Cloud Map
Conexión a BD (Catalog → PostgreSQL) Pool de conexiones de Catalog a PostgreSQL. Ejecuta SELECT FOR UPDATE + INSERT en la tabla inventory_calendar. Bajo alta contención, las conexiones pueden quedar esperando la liberación de locks. asyncpg + SQLAlchemy async + RDS
Conexión a BD (Booking → PostgreSQL) Pool de conexiones de Booking a PostgreSQL. Ejecuta INSERT en la tabla booking. Sin contención esperada (cada booking es un registro nuevo). asyncpg + SQLAlchemy async + RDS

Ficha de Resumen

Tecnología asociada Justificación
Lenguaje de programación Python 3.11+ — lenguaje definido por el proyecto para todos los microservicios
Plataforma de despliegue AWS ECS Fargate — orquestación serverless de contenedores, consistente con la arquitectura de producción
Base de datos Amazon RDS PostgreSQL (t3g.small) — misma tecnología de producción; instancia mínima suficiente para validar el comportamiento bajo contención
Herramientas de análisis Locust (generador de carga), Amazon CloudWatch (métricas de infraestructura), logs de aplicación (latencias internas)
Librerías FastAPI, asyncpg o SQLAlchemy async (connection pool), httpx o aiohttp (cliente HTTP async), Pydantic (validación)
Frameworks FastAPI (framework web async de los microservicios), Locust (framework de pruebas de carga)

Distribución de actividades por integrante

Integrante Tareas a realizar Esfuerzo estimado
Isaac Blanco Implementar endpoint createHold en Catalog Service (SELECT FOR UPDATE + INSERT) y esquema de BD de inventario. Configurar connection pool. 5h
Nicolás Calero Implementar endpoint checkout-start en Booking Service (llamada HTTP a Catalog + persistencia de booking). Configurar Cloud Map. 5h
José García Configurar infraestructura AWS (ECS, ALB, RDS, Cloud Map, EC2 para carga). Scripts de IaC o setup manual documentado. 6h
Raúl López Diseñar y ejecutar escenarios de carga con Locust. Recolectar métricas, analizar resultados y documentar conclusiones del experimento. 5h
⚠️ **GitHub.com Fallback** ⚠️