Experimento 1 - galoryzen/equipo8-pfinal GitHub Wiki

Experimento 1
Título del experimento Validación de latencia de búsqueda de hospedaje con patrón cache-aside (Redis) bajo carga pico
Propósito del experimento Validar que la táctica de múltiples copias de datos (cache-aside con Redis) permite al Catalog Service cumplir el SLA de latencia p95 ≤ 800ms para búsquedas de hospedaje bajo carga pico, y determinar el impacto del cache hit ratio en el cumplimiento del SLA.
Resultados esperados Determinar si la latencia p95 del endpoint GET /api/catalog/search se mantiene por debajo de 800ms bajo los escenarios de carga definidos, e identificar el umbral de hit ratio por debajo del cual el SLA se quiebra.
Recursos requeridos AWS: 1 tarea ECS Fargate (Catalog Service), 1 ALB, 1 instancia RDS PostgreSQL, 1 nodo ElastiCache Redis. Local: Locust. Herramientas: Locust, CloudWatch.
Elementos de arquitectura involucrados Catalog Service, ALB, Redis (ElastiCache), PostgreSQL (esquema catalog), Cloud Map (service discovery)
Esfuerzo estimado 20 horas / hombre 
sequenceDiagram
    participant LC as Generador de Carga
    participant ALB as ALB
    participant CAT as Catalog Service
    participant REDIS as Redis (ElastiCache)
    participant DB as PostgreSQL

    Note over LC: N usuarios concurrentes<br/>simulando búsquedas

    LC->>ALB: GET /api/catalog/search?city=...&dates=...
    ALB->>CAT: Enruta petición

    CAT->>REDIS: GET cache_key(city, dates, capacity)

    alt Cache HIT
        REDIS-->>CAT: Resultados cacheados
    else Cache MISS
        REDIS-->>CAT: null
        Note over CAT,DB: Punto de sensibilidad:<br/>hit ratio bajo = más queries a BD
        CAT->>DB: SELECT properties WHERE filters
        DB-->>CAT: Resultados
        CAT->>REDIS: SET cache_key (TTL 1-2 min)
    end

    CAT-->>ALB: 200 resultados
    ALB-->>LC: 200 resultados

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

Hipótesis de diseño
Punto de sensibilidad El Catalog Service implementa cache-aside con Redis: ante cada búsqueda, primero consulta Redis y solo va a PostgreSQL si hay cache miss. El TTL del caché es de 1-2 minutos. Si la frecuencia de invalidaciones es alta (actualizaciones de disponibilidad, tarifas) o la variedad de queries es muy amplia, el hit ratio caerá y la mayoría de búsquedas golpearán directamente a PostgreSQL, aumentando la latencia. No conocemos el hit ratio efectivo bajo carga real ni el umbral donde el SLA se quiebra.
Historia de Arquitectura asociada ASR-01: Búsqueda de hospedaje en tiempo objetivo (≤ 800ms p95)
Como viajero que busca hospedaje por ciudad, fechas y capacidad, cuando realice una búsqueda en hora pico, quiero recibir resultados disponibles en menos de 800ms (p95), de modo que la experiencia de búsqueda sea fluida.
Nivel de incertidumbre Medio. Se espera que con cache hit la latencia sea significativamente menor que con cache miss, pero no tenemos datos reales de ninguno de los dos escenarios. No sabemos cuál será el hit ratio efectivo bajo carga pico real, ni si la combinación de queries diversas + invalidaciones frecuentes degradará la latencia más allá del SLA.

Estilos y Tácticas de arquitectura

Estilo (C&C) Análisis
Llamado-Retorno (Cliente-Servidor) El ALB enruta peticiones de búsqueda al Catalog Service, que responde sincrónicamente con los resultados. El estilo favorece el desempeño (respuesta inmediata al usuario). Pero desfavorece la disponibilidad, ya que si el Catalog Service falla, las búsquedas dejan de funcionar.
Orientado a Depósitos (Datos Compartidos) Redis y PostgreSQL son almacenes de datos compartidos que el Catalog Service consume. El estilo favorece la simplicidad operacional (un solo servicio accede a ambos stores). Pero desfavorece el desempeño bajo alta concurrencia si el caché tiene bajo hit ratio, ya que las queries caen directamente a la BD.
Táctica Análisis
Múltiples copias de datos Cache-aside con Redis replica los resultados de búsqueda desde PostgreSQL a Redis. Reduce la latencia de ~50-200ms (BD) a ~5-20ms (caché) y disminuye la carga de lectura en la BD en un estimado de 60-70%. Es la táctica principal bajo evaluación.
Manejar la rata de muestreo El TTL del caché (1-2 min) controla la frecuencia con la que se refrescan los datos desde PostgreSQL. Un TTL corto garantiza datos más frescos pero reduce el hit ratio; un TTL largo mejora el hit ratio pero puede servir datos desactualizados.
Introducir concurrencia FastAPI con async/await permite que el Catalog Service procese múltiples búsquedas de forma concurrente sin bloquear hilos. Esto es clave para mantener el throughput cuando hay muchas búsquedas simultáneas, especialmente durante cache misses que esperan respuesta de la BD.
Planificar el uso de los recursos Connection pooling a PostgreSQL (asyncpg) y a Redis (redis-py async) reutiliza conexiones existentes. Evita el overhead de establecimiento de conexión y controla el número máximo de conexiones concurrentes a cada store.

Listado de componentes

Componente Propósito y comportamiento esperado Tecnología asociada
Catalog Service Recibe las búsquedas de hospedaje, implementa la lógica cache-aside (consulta Redis primero, PostgreSQL en cache miss), aplica filtros y ranking, y retorna los resultados. Es el servicio bajo prueba. FastAPI (Python), ECS Fargate
Redis Almacena resultados de búsqueda cacheados con TTL de 1-2 minutos. Claves compuestas por criterios de búsqueda (ciudad, fechas, capacidad). Es el componente cuyo hit ratio determina el comportamiento de latencia. Amazon ElastiCache Redis
PostgreSQL Almacena el catálogo de propiedades, disponibilidad y tarifas (esquema catalog). Responde queries de búsqueda en cache miss. Optimizado con índices en columnas de filtro (ciudad, fechas, capacidad). Amazon RDS PostgreSQL
Generador de carga Simula múltiples usuarios concurrentes haciendo búsquedas a GET /api/catalog/search a través del ALB. Mide latencia end-to-end, throughput, tasa de error y permite variar patrones de búsqueda para afectar el hit ratio. Locust (local)
ALB Punto de entrada que enruta las peticiones al Catalog 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 → Catalog) Enruta peticiones del generador de carga al Catalog Service. Se espera latencia baja. No debería ser cuello de botella. ALB + Target Group
Conexión a caché (Catalog → Redis) Lectura/escritura cache-aside. En cache hit retorna resultados en ~1-5ms. En cache miss retorna null y el Catalog Service procede a consultar PostgreSQL. Es el conector cuyo comportamiento (hit/miss) define la latencia. redis-py async + ElastiCache
Conexión a BD (Catalog → PostgreSQL) Pool de conexiones del Catalog Service a PostgreSQL. Ejecuta queries de búsqueda con filtros e índices. Solo se invoca en cache miss. Bajo hit ratio bajo, la cantidad de queries a BD aumenta y puede generar carga. SQLAlchemy async + asyncpg + 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 — misma tecnología de producción; índices en columnas de filtro para optimizar queries de búsqueda
Caché Amazon ElastiCache Redis — implementa el patrón cache-aside que es la táctica principal bajo evaluación
Herramientas de análisis Locust (generador de carga y métricas de latencia), Amazon CloudWatch (métricas de infraestructura: CPU, memoria, conexiones)
Librerías FastAPI, SQLAlchemy async con asyncpg (connection pool a BD), redis-py async (connection pool a Redis), httpx (cliente HTTP), Pydantic (validación)
Frameworks FastAPI (framework web async del microservicio), Locust (framework de pruebas de carga)

Distribución de actividades por integrante

Integrante Tareas a realizar Esfuerzo estimado
Isaac Blanco Implementar lógica cache-aside en Catalog Service (integración con Redis, TTL, claves compuestas) y esquema de BD con índices en columnas de filtro. 5h
Nicolás Calero Implementar endpoint GET /api/catalog/search en Catalog Service (filtros, queries a BD, ranking) y connection pooling a PostgreSQL y Redis. 5h
José García Configurar infraestructura AWS (ECS, ALB, RDS, ElastiCache Redis, EC2 para carga). Pre-cargar datos de prueba (propiedades, disponibilidad, tarifas). 5h
Raúl López Diseñar y ejecutar escenarios de carga con Locust (variando patrones de búsqueda para afectar hit ratio). Recolectar métricas, analizar resultados y documentar conclusiones. 5h
⚠️ **GitHub.com Fallback** ⚠️