Request síncrono

Fluxo completo de um request síncrono desde o frontend, passando por API Gateway, BFF e microsserviço, até o banco de dados e de volta.

O que é um request síncrono

Um request síncrono é uma chamada em que o cliente envia uma requisição e espera uma resposta antes de continuar. É o modelo mais natural para interações em que o usuário precisa ver um resultado imediato: carregar uma página, enviar um formulário, consultar um dado.

Nesta arquitetura, um request síncrono atravessa várias camadas antes de chegar aos dados e voltar com a resposta.

O caminho completo de um request

O fluxo típico segue esta sequência:

1. O frontend dispara uma ação do usuário (clique, navegação, envio de formulário)
2. A requisição chega ao API Gateway
3. O Gateway a roteia para o BFF correspondente
4. O BFF invoca um ou mais microsserviços
5. O microsserviço consulta seu banco de dados
6. A resposta percorre o caminho inverso até o 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

O que cada camada faz no caminho de ida

Frontend

• Monta a requisição HTTP (método, headers, body)
• Inclui o token de autenticação (JWT) no header Authorization
• Exibe um estado de carregamento enquanto espera

API Gateway

• Valida o token JWT
• Aplica rate limiting por cliente ou IP
• Registra a requisição no log de acesso
• Roteia para o BFF correto conforme a rota e o método

BFF

• Recebe a requisição já autenticada
• Determina quais microsserviços precisa invocar
• Se precisar de dados de vários serviços, os orquestra (em série ou em paralelo)
• Transforma a resposta no formato que o frontend espera

Microsserviço

• Recebe uma requisição focada em seu domínio
• Executa a lógica de negócio correspondente
• Consulta ou modifica seu banco de dados
• Retorna uma resposta de domínio limpa

Banco de dados

• Executa a query ou o comando
• Retorna os dados solicitados ou confirma a operação

O que cada camada faz no caminho de volta

O caminho de volta é igualmente importante:

• O banco de dados retorna os dados brutos
• O microsserviço os envolve em uma resposta de domínio, aplicando qualquer transformação de negócio
• O BFF adapta a resposta ao contrato que o frontend espera (pode renomear campos, achatar estruturas, combinar dados de vários serviços)
• O API Gateway adiciona headers de segurança e logging
• O frontend recebe a resposta e atualiza a interface

Tempos e latência

Cada camada adiciona latência. Em um request síncrono típico:

O tempo total percebido pelo usuário é a soma de todas as camadas. Por isso é crítico que cada camada seja eficiente e que o BFF minimize as chamadas sequenciais.

Estratégias para reduzir latência

Chamadas em paralelo a partir do BFF

Se o BFF precisar de dados de dois microsserviços independentes, pode invocá-los em paralelo em vez de em série.

Cache no BFF ou no Gateway

Para dados que mudam pouco (catálogos, configurações), uma camada de cache pode evitar chegar até o banco de dados.

Connection pooling

Manter conexões abertas entre camadas reduz o overhead de estabelecer novas conexões a cada request.

Respostas parciais

Em alguns casos, o BFF pode retornar uma resposta parcial rápida e completar os dados em um segundo request.

Tratamento de erros no fluxo síncrono

Quando algo falha em qualquer camada, o erro deve se propagar de forma controlada:

• O microsserviço retorna um código de erro HTTP apropriado (400, 404, 500)
• O BFF traduz erros de domínio em erros compreensíveis para o frontend
• O Gateway pode interceptar erros de infraestrutura (503, 502)
• O frontend exibe uma mensagem adequada ao usuário

O importante é que cada camada não exponha detalhes internos das camadas inferiores. O frontend nunca deveria ver um stack trace do banco de dados.

Quando usar comunicação síncrona

A comunicação síncrona é adequada quando:

• O usuário precisa de uma resposta imediata
• A operação é de leitura ou de escrita simples
• O tempo de resposta esperado é baixo (< 2 segundos)
• Não há processos longos ou dependências externas lentas

Não é adequada quando:

• A operação pode demorar muito (processamento de arquivos, integrações externas lentas)
• Não é necessária uma resposta imediata (notificações, analytics)
• Deseja-se desacoplar temporalmente os serviços

Resumo

O request síncrono é o fluxo mais comum e direto na arquitetura. Atravessa todas as camadas de forma sequencial, cada uma adicionando sua responsabilidade específica. A chave está em manter cada camada eficiente, tratar erros de forma limpa e usar estratégias como cache e paralelismo para manter a latência sob controle.