Request sincrónico

Flujo completo de un request sincrónico desde el frontend, pasando por API Gateway, BFF y microservicio, hasta la base de datos y de vuelta.

Qué es un request sincrónico

Un request sincrónico es una llamada donde el cliente envía una petición y espera una respuesta antes de continuar. Es el modelo más natural para interacciones donde el usuario necesita ver un resultado inmediato: cargar una página, enviar un formulario, consultar un dato.

En esta arquitectura, un request sincrónico atraviesa varias capas antes de llegar a los datos y volver con la respuesta.

El camino completo de un request

El flujo típico sigue esta secuencia:

1. El frontend dispara una acción del usuario (clic, navegación, envío de formulario)
2. La petición llega al API Gateway
3. El Gateway la enruta al BFF correspondiente
4. El BFF invoca uno o más microservicios
5. El microservicio consulta su base de datos
6. La respuesta recorre el camino inverso hasta el 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

Qué hace cada capa en el camino de ida

Frontend

• Construye la petición HTTP (método, headers, body)
• Incluye el token de autenticación (JWT) en el header Authorization
• Muestra un estado de carga mientras espera

API Gateway

• Valida el token JWT
• Aplica rate limiting por cliente o IP
• Registra la petición en el log de acceso
• Enruta al BFF correcto según la ruta y el método

BFF

• Recibe la petición ya autenticada
• Determina qué microservicios necesita invocar
• Si necesita datos de varios servicios, los orquesta (en serie o en paralelo)
• Transforma la respuesta al formato que el frontend espera

Microservicio

• Recibe una petición enfocada en su dominio
• Ejecuta la lógica de negocio correspondiente
• Consulta o modifica su base de datos
• Devuelve una respuesta de dominio limpia

Base de datos

• Ejecuta la query o el comando
• Devuelve los datos solicitados o confirma la operación

Qué hace cada capa en el camino de vuelta

El camino de vuelta es igual de importante:

• La base de datos devuelve los datos crudos
• El microservicio los envuelve en una respuesta de dominio, aplicando cualquier transformación de negocio
• El BFF adapta la respuesta al contrato que el frontend espera (puede renombrar campos, aplanar estructuras, combinar datos de varios servicios)
• El API Gateway añade headers de seguridad y logging
• El frontend recibe la respuesta y actualiza la interfaz

Tiempos y latencia

Cada capa añade latencia. En un request sincrónico típico:

El tiempo total percibido por el usuario es la suma de todas las capas. Por eso es crítico que cada capa sea eficiente y que el BFF minimice las llamadas secuenciales.

Estrategias para reducir latencia

Llamadas en paralelo desde el BFF

Si el BFF necesita datos de dos microservicios independientes, puede invocarlos en paralelo en lugar de en serie.

Caché en el BFF o en el Gateway

Para datos que cambian poco (catálogos, configuraciones), una capa de caché puede evitar llegar hasta la base de datos.

Connection pooling

Mantener conexiones abiertas entre capas reduce el overhead de establecer conexiones nuevas en cada request.

Respuestas parciales

En algunos casos, el BFF puede devolver una respuesta parcial rápida y completar los datos en un segundo request.

Manejo de errores en el flujo sincrónico

Cuando algo falla en cualquier capa, el error debe propagarse de forma controlada:

• El microservicio devuelve un código de error HTTP apropiado (400, 404, 500)
• El BFF traduce errores de dominio a errores comprensibles para el frontend
• El Gateway puede interceptar errores de infraestructura (503, 502)
• El frontend muestra un mensaje adecuado al usuario

Lo importante es que cada capa no exponga detalles internos de las capas inferiores. El frontend nunca debería ver un stack trace de la base de datos.

Cuándo usar comunicación sincrónica

La comunicación sincrónica es adecuada cuando:

• El usuario necesita una respuesta inmediata
• La operación es de lectura o de escritura simple
• El tiempo de respuesta esperado es bajo (< 2 segundos)
• No hay procesos largos o dependencias externas lentas

No es adecuada cuando:

• La operación puede tardar mucho (procesamiento de archivos, integraciones externas lentas)
• No se necesita una respuesta inmediata (notificaciones, analytics)
• Se quiere desacoplar temporalmente los servicios

Resumen

El request sincrónico es el flujo más común y directo en la arquitectura. Atraviesa todas las capas de forma secuencial, cada una añadiendo su responsabilidad específica. La clave está en mantener cada capa eficiente, manejar errores de forma limpia y usar estrategias como caché y paralelismo para mantener la latencia bajo control.