Consultation du catalogue

Flux de consultation du catalogue : du frontend jusqu'au microservice de catalogue, en passant par la base de données et la couche de cache pour optimiser les réponses.

Pourquoi la consultation du catalogue est un flux représentatif

La consultation du catalogue est l’un des flux les plus fréquents dans toute application de commerce ou de gestion. C’est un cas de lecture intensive : de nombreux utilisateurs consultent les mêmes données, celles-ci changent rarement et la rapidité de réponse a un impact direct sur l’expérience utilisateur.

Ce flux illustre comment l’architecture gère les lectures optimisées avec du cache et comment le BFF adapte les données pour le frontend.

Le flux complet

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

Ce que fait chaque couche

Frontend

1. L’utilisateur navigue vers une catégorie ou utilise le moteur de recherche
2. Le frontend construit la requête avec des filtres (catégorie, prix, tri)
3. Il envoie la requête au Gateway
4. Il reçoit les produits et les affiche dans une grille ou une liste
5. Il peut mettre en œuvre la pagination ou le défilement infini

API Gateway

1. Il valide le token JWT de l’utilisateur
2. Il applique le rate limiting (les consultations du catalogue peuvent être très fréquentes)
3. Il route vers le BFF

BFF

C’est au niveau du BFF que se déroule la plus grande partie de l’optimisation :

1. Il reçoit la requête avec les filtres du frontend
2. Il interroge le cache pour voir s’il possède déjà les données
3. En cas de cache hit, il renvoie directement les données mises en cache
4. En cas de cache miss, il invoque le microservice de catalogue
5. Il enregistre la réponse dans le cache avec un TTL approprié
6. Il transforme les données au format dont le frontend a besoin

Microservice de catalogue (ms-catalog)

1. Il reçoit la requête avec les filtres
2. Il construit la requête vers la base de données
3. Il applique la pagination, le tri et les filtres
4. Il renvoie les produits avec leurs données de domaine

Base de données

• Elle stocke les produits, catégories, prix, stock
• Elle possède des index optimisés pour les requêtes les plus fréquentes
• Elle peut utiliser des vues matérialisées pour les requêtes complexes

La couche de cache en détail

Où placer le cache

Il existe plusieurs options, qui peuvent être combinées :

Dans cette architecture, le cache principal se trouve au niveau du BFF, car c’est le point où l’on peut le mieux contrôler la transformation et l’invalidation.

Stratégie d’invalidation

Le cache du catalogue est invalidé de deux façons :

Par TTL (Time To Live) : chaque entrée a une durée de vie (par exemple, 5 minutes). Passé ce délai, elle est considérée comme obsolète et le microservice est interrogé de nouveau.

Par événement : lorsque le microservice de catalogue met à jour un produit, il publie un événement ProductUpdated. Le BFF écoute cet événement et invalide les entrées de cache concernées.

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

Les clés de cache doivent être déterministes et refléter les paramètres de la requête :

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

Transformation dans le BFF

Le microservice renvoie des données de domaine complètes, mais le frontend n’a pas besoin de tout. Le BFF transforme :

Réponse du microservice :

{
  "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"
}

Réponse du BFF au frontend :

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

Le BFF supprime les données internes (internalSku, warehouseLocation), formate le prix, simplifie le stock en un booléen et résout la catégorie vers son nom lisible.

Pagination et performance

Pour les grands catalogues, la pagination est essentielle :

• Le frontend envoie page et pageSize
• Le microservice applique LIMIT et OFFSET dans la requête
• La réponse inclut des métadonnées de pagination (totalItems, totalPages, currentPage)
• Chaque page est mise en cache indépendamment

Scénarios d’erreur

Microservice indisponible

Si le microservice de catalogue est hors service mais qu’il existe des données en cache (même expirées), le BFF peut renvoyer les données obsolètes avec un en-tête indiquant qu’elles sont stale. C’est préférable à l’affichage d’une erreur à l’utilisateur.

Cache indisponible

Si Redis est hors service, le BFF interroge simplement le microservice directement. La latence augmente, mais le flux ne se rompt pas.

Requête sans résultat

Ce n’est pas une erreur. Le microservice renvoie une liste vide et le frontend affiche un message « Aucun produit trouvé ».

Résumé

La consultation du catalogue montre comment l’architecture optimise les flux de lecture intensive. Le cache au niveau du BFF réduit la charge sur le microservice et la base de données, tandis que l’invalidation par événements maintient les données raisonnablement fraîches. Le BFF transforme les données de domaine au format dont le frontend a besoin, tout en préservant la séparation des responsabilités entre les couches.