Consulta de catálogo

Flujo de consulta de catálogo: desde el frontend hasta el microservicio de catálogo, pasando por la base de datos y la capa de caché para optimizar respuestas.

Por qué la consulta de catálogo es un flujo representativo

La consulta de catálogo es uno de los flujos más frecuentes en cualquier aplicación de comercio o gestión. Es un caso de lectura intensiva: muchos usuarios consultan los mismos datos, los datos cambian con poca frecuencia y la velocidad de respuesta impacta directamente en la experiencia del usuario.

Este flujo ilustra cómo la arquitectura maneja lecturas optimizadas con caché y cómo el BFF adapta los datos para el frontend.

El flujo completo

sequenceDiagram
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant CACHE as Caché
    participant MS as ms-catalog
    participant DB as Catalog DB

    FE->>GW: GET /catalog/products?category=electronics
    GW->>GW: Auth, rate limiting
    GW->>BFF: Forward

    BFF->>CACHE: ¿Datos en caché?
    alt Cache HIT
        CACHE-->>BFF: Datos cacheados
    else Cache MISS
        BFF->>MS: GET /products?category=electronics
        MS->>DB: SELECT * FROM products WHERE category = ...
        DB-->>MS: Resultados
        MS-->>BFF: Lista de productos
        BFF->>CACHE: Guardar en caché (TTL: 5 min)
    end

    BFF->>BFF: Transformar para UI
    BFF-->>GW: Respuesta formateada
    GW-->>FE: 200 OK + productos

Qué hace cada capa

Frontend

1. El usuario navega a una categoría o usa el buscador
2. El frontend construye la petición con filtros (categoría, precio, orden)
3. Envía la petición al Gateway
4. Recibe los productos y los renderiza en un grid o lista
5. Puede implementar paginación o scroll infinito

API Gateway

1. Valida el token JWT del usuario
2. Aplica rate limiting (las consultas de catálogo pueden ser muy frecuentes)
3. Enruta al BFF

BFF

El BFF es donde ocurre la mayor parte de la optimización:

1. Recibe la petición con los filtros del frontend
2. Consulta la caché para ver si ya tiene los datos
3. Si hay cache hit, devuelve los datos cacheados directamente
4. Si hay cache miss, invoca al microservicio de catálogo
5. Guarda la respuesta en caché con un TTL apropiado
6. Transforma los datos al formato que el frontend necesita

Microservicio de catálogo (ms-catalog)

1. Recibe la consulta con los filtros
2. Construye la query a la base de datos
3. Aplica paginación, ordenamiento y filtros
4. Devuelve los productos con sus datos de dominio

Base de datos

• Almacena productos, categorías, precios, stock
• Tiene índices optimizados para las consultas más frecuentes
• Puede usar vistas materializadas para consultas complejas

La capa de caché en detalle

Dónde ubicar la caché

Hay varias opciones, y pueden combinarse:

En esta arquitectura, la caché principal está en el BFF porque es el punto donde se puede controlar mejor la transformación y la invalidación.

Estrategia de invalidación

La caché del catálogo se invalida de dos formas:

Por TTL (Time To Live): cada entrada tiene un tiempo de vida (por ejemplo, 5 minutos). Después de ese tiempo, se considera obsoleta y se consulta de nuevo al microservicio.

Por evento: cuando el microservicio de catálogo actualiza un producto, publica un evento ProductUpdated. El BFF escucha ese evento e invalida las entradas de caché afectadas.

sequenceDiagram
    participant ADMIN as Admin
    participant MS as ms-catalog
    participant EB as Event Bus
    participant BFF as BFF
    participant CACHE as Caché

    ADMIN->>MS: PUT /products/123 (actualizar precio)
    MS->>MS: Actualizar en DB
    MS->>EB: Publicar ProductUpdated
    EB->>BFF: Evento ProductUpdated
    BFF->>CACHE: Invalidar entradas relacionadas

Cache key design

Las claves de caché deben ser deterministas y reflejar los parámetros de la consulta:

catalog:products:category=electronics:sort=price:page=1
catalog:products:category=electronics:sort=price:page=2
catalog:product:123

Transformación en el BFF

El microservicio devuelve datos de dominio completos, pero el frontend no necesita todo. El BFF transforma:

Respuesta del microservicio:

{
  "id": "prod-123",
  "internalSku": "SKU-2024-001",
  "name": "Laptop Pro",
  "description": "...",
  "priceInCents": 99900,
  "currency": "USD",
  "stockQuantity": 45,
  "warehouseLocation": "A-12-3",
  "categoryId": "cat-electronics",
  "createdAt": "2024-01-01T00:00:00Z",
  "updatedAt": "2024-01-15T10:00:00Z"
}

Respuesta del BFF al frontend:

{
  "id": "prod-123",
  "name": "Laptop Pro",
  "description": "...",
  "price": "$999.00",
  "inStock": true,
  "category": "Electrónica",
  "imageUrl": "/images/prod-123.jpg"
}

El BFF elimina datos internos (internalSku, warehouseLocation), formatea el precio, simplifica el stock a un booleano y resuelve la categoría a su nombre legible.

Paginación y rendimiento

Para catálogos grandes, la paginación es esencial:

• El frontend envía page y pageSize
• El microservicio aplica LIMIT y OFFSET en la query
• La respuesta incluye metadata de paginación (totalItems, totalPages, currentPage)
• Cada página se cachea independientemente

Escenarios de error

Microservicio no disponible

Si el microservicio de catálogo está caído pero hay datos en caché (aunque estén expirados), el BFF puede devolver los datos obsoletos con un header indicando que son stale. Esto es mejor que mostrar un error al usuario.

Caché no disponible

Si Redis está caído, el BFF simplemente consulta al microservicio directamente. La latencia aumenta pero el flujo no se rompe.

Consulta sin resultados

No es un error. El microservicio devuelve una lista vacía y el frontend muestra un mensaje de “No se encontraron productos”.

Resumen

La consulta de catálogo muestra cómo la arquitectura optimiza flujos de lectura intensiva. La caché en el BFF reduce la carga sobre el microservicio y la base de datos, mientras que la invalidación por eventos mantiene los datos razonablemente frescos. El BFF transforma los datos de dominio al formato que el frontend necesita, manteniendo la separación de responsabilidades entre capas.