Synchronous request

The complete flow of a synchronous request from the frontend, through the API Gateway, BFF and microservice, down to the database and back.

What a synchronous request is

A synchronous request is a call where the client sends a request and waits for a response before continuing. It is the most natural model for interactions where the user needs to see an immediate result: loading a page, submitting a form, querying a piece of data.

In this architecture, a synchronous request crosses several layers before reaching the data and coming back with the response.

The complete path of a request

The typical flow follows this sequence:

1. The frontend triggers a user action (click, navigation, form submission)
2. The request reaches the API Gateway
3. The Gateway routes it to the corresponding BFF
4. The BFF invokes one or more microservices
5. The microservice queries its database
6. The response travels back the reverse path to the 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

What each layer does on the way in

Frontend

• Builds the HTTP request (method, headers, body)
• Includes the authentication token (JWT) in the Authorization header
• Shows a loading state while it waits

API Gateway

• Validates the JWT token
• Applies rate limiting per client or IP
• Records the request in the access log
• Routes to the correct BFF based on the path and method

BFF

• Receives the already authenticated request
• Determines which microservices it needs to invoke
• If it needs data from several services, it orchestrates them (in series or in parallel)
• Transforms the response into the format the frontend expects

Microservice

• Receives a request focused on its domain
• Runs the corresponding business logic
• Queries or modifies its database
• Returns a clean domain response

Database

• Executes the query or command
• Returns the requested data or confirms the operation

What each layer does on the way back

The return path is just as important:

• The database returns the raw data
• The microservice wraps it in a domain response, applying any business transformation
• The BFF adapts the response to the contract the frontend expects (it can rename fields, flatten structures, combine data from several services)
• The API Gateway adds security and logging headers
• The frontend receives the response and updates the interface

Timing and latency

Each layer adds latency. In a typical synchronous request:

The total time perceived by the user is the sum of all the layers. That is why it is critical that each layer is efficient and that the BFF minimizes sequential calls.

Strategies to reduce latency

Parallel calls from the BFF

If the BFF needs data from two independent microservices, it can invoke them in parallel instead of in series.

Caching in the BFF or the Gateway

For data that changes rarely (catalogs, configurations), a caching layer can avoid reaching the database.

Connection pooling

Keeping connections open between layers reduces the overhead of establishing new connections on every request.

Partial responses

In some cases, the BFF can return a quick partial response and complete the data in a second request.

Error handling in the synchronous flow

When something fails in any layer, the error must propagate in a controlled way:

• The microservice returns an appropriate HTTP error code (400, 404, 500)
• The BFF translates domain errors into errors that the frontend can understand
• The Gateway can intercept infrastructure errors (503, 502)
• The frontend shows a suitable message to the user

The important thing is that each layer does not expose internal details of the lower layers. The frontend should never see a database stack trace.

When to use synchronous communication

Synchronous communication is suitable when:

• The user needs an immediate response
• The operation is a read or a simple write
• The expected response time is low (< 2 seconds)
• There are no long-running processes or slow external dependencies

It is not suitable when:

• The operation may take a long time (file processing, slow external integrations)
• An immediate response is not needed (notifications, analytics)
• You want to temporally decouple the services

Summary

The synchronous request is the most common and direct flow in the architecture. It crosses all the layers sequentially, each one adding its specific responsibility. The key is to keep each layer efficient, handle errors cleanly, and use strategies like caching and parallelism to keep latency under control.