Requête synchrone

Flux complet d'une requête synchrone depuis le frontend, en passant par l'API Gateway, le BFF et le microservice, jusqu'à la base de données et retour.

Qu’est-ce qu’une requête synchrone

Une requête synchrone est un appel où le client envoie une demande et attend une réponse avant de poursuivre. C’est le modèle le plus naturel pour les interactions où l’utilisateur a besoin de voir un résultat immédiat : charger une page, soumettre un formulaire, consulter une donnée.

Dans cette architecture, une requête synchrone traverse plusieurs couches avant d’atteindre les données et de revenir avec la réponse.

Le parcours complet d’une requête

Le flux typique suit cette séquence :

1. Le frontend déclenche une action de l’utilisateur (clic, navigation, envoi de formulaire)
2. La requête arrive à l’API Gateway
3. La Gateway l’achemine vers le BFF correspondant
4. Le BFF invoque un ou plusieurs microservices
5. Le microservice interroge sa base de données
6. La réponse parcourt le chemin inverse jusqu’au frontend

sequenceDiagram
    participant FE as Frontend
    participant GW as API Gateway
    participant BFF as BFF
    participant MS as Microservicio
    participant DB as Base de Datos

    FE->>GW: HTTP Request
    GW->>GW: Autenticación, rate limiting
    GW->>BFF: Forward request
    BFF->>MS: Llamada al servicio de dominio
    MS->>DB: Query
    DB-->>MS: Resultado
    MS-->>BFF: Respuesta de dominio
    BFF-->>GW: Respuesta transformada para UI
    GW-->>FE: HTTP Response

Ce que fait chaque couche à l’aller

Frontend

• Construit la requête HTTP (méthode, headers, body)
• Inclut le token d’authentification (JWT) dans le header Authorization
• Affiche un état de chargement pendant l’attente

API Gateway

• Valide le token JWT
• Applique le rate limiting par client ou par IP
• Enregistre la requête dans le log d’accès
• Achemine vers le bon BFF selon la route et la méthode

BFF

• Reçoit la requête déjà authentifiée
• Détermine quels microservices il doit invoquer
• S’il a besoin de données de plusieurs services, il les orchestre (en série ou en parallèle)
• Transforme la réponse au format attendu par le frontend

Microservice

• Reçoit une requête ciblée sur son domaine
• Exécute la logique métier correspondante
• Interroge ou modifie sa base de données
• Renvoie une réponse de domaine propre

Base de données

• Exécute la query ou la commande
• Renvoie les données demandées ou confirme l’opération

Ce que fait chaque couche au retour

Le chemin de retour est tout aussi important :

• La base de données renvoie les données brutes
• Le microservice les enveloppe dans une réponse de domaine, en appliquant toute transformation métier
• Le BFF adapte la réponse au contrat attendu par le frontend (il peut renommer des champs, aplatir des structures, combiner des données de plusieurs services)
• L’API Gateway ajoute les headers de sécurité et le logging
• Le frontend reçoit la réponse et met à jour l’interface

Temps et latence

Chaque couche ajoute de la latence. Dans une requête synchrone typique :

Le temps total perçu par l’utilisateur est la somme de toutes les couches. C’est pourquoi il est essentiel que chaque couche soit efficace et que le BFF minimise les appels séquentiels.

Stratégies pour réduire la latence

Appels en parallèle depuis le BFF

Si le BFF a besoin de données de deux microservices indépendants, il peut les invoquer en parallèle plutôt qu’en série.

Cache dans le BFF ou dans la Gateway

Pour des données qui changent peu (catalogues, configurations), une couche de cache peut éviter d’atteindre la base de données.

Connection pooling

Maintenir des connexions ouvertes entre les couches réduit le surcoût lié à l’établissement de nouvelles connexions à chaque requête.

Réponses partielles

Dans certains cas, le BFF peut renvoyer une réponse partielle rapide et compléter les données lors d’une seconde requête.

Gestion des erreurs dans le flux synchrone

Lorsqu’un incident survient dans une couche, l’erreur doit se propager de manière contrôlée :

• Le microservice renvoie un code d’erreur HTTP approprié (400, 404, 500)
• Le BFF traduit les erreurs de domaine en erreurs compréhensibles pour le frontend
• La Gateway peut intercepter les erreurs d’infrastructure (503, 502)
• Le frontend affiche un message adapté à l’utilisateur

L’essentiel est que chaque couche n’expose pas les détails internes des couches inférieures. Le frontend ne devrait jamais voir une stack trace de la base de données.

Quand utiliser la communication synchrone

La communication synchrone convient lorsque :

• L’utilisateur a besoin d’une réponse immédiate
• L’opération est une lecture ou une écriture simple
• Le temps de réponse attendu est faible (< 2 secondes)
• Il n’y a pas de processus longs ni de dépendances externes lentes

Elle ne convient pas lorsque :

• L’opération peut prendre beaucoup de temps (traitement de fichiers, intégrations externes lentes)
• Une réponse immédiate n’est pas nécessaire (notifications, analytics)
• On souhaite découpler temporellement les services

Résumé

La requête synchrone est le flux le plus courant et le plus direct de l’architecture. Elle traverse toutes les couches de manière séquentielle, chacune ajoutant sa responsabilité spécifique. La clé consiste à maintenir chaque couche efficace, à gérer les erreurs proprement et à recourir à des stratégies comme le cache et le parallélisme pour garder la latence sous contrôle.