Execução Síncrona

A Execução Síncrona é o modo de processamento em que a requisição HTTP aberta pelo cliente é mantida suspensa pela Engine enquanto as etapas do fluxo são orquestradas e executadas pelos runners. Ao término do fluxo, a Engine consolida o estado final da sessão, aplica os adaptadores de saída e devolve a resposta HTTP diretamente ao cliente.

Ciclo de Vida da Requisição Síncrona

O processamento síncrono combina a leveza das Threads Virtuais com o envio leve de notificações em memória via PubSub do Cache para aguardar a conclusão sem bloquear threads do sistema operacional ou gerar overhead no barramento de eventos:

Cliente HTTP                 Engine                      Barramento / Runners            Cache (PubSub)
     │                         │                                  │                            │
     │── 1. POST /public... ──►│                                  │                            │
     │                         │── 2. Valida e cria Sessão ──────►│                            │
     │                         │── 3. Reg. CompletableFuture      │                            │
     │                         │    e suspende Thread Virtual     │                            │
     │                         │                                  │── 4. Executa Etapas ──────►│
     │                         │                                  │   (Processa e finaliza)    │
     │                         │                                  │                            │
     │                         │◄── 5. Notificação inbox:{host} ──┴────────────────────────────│
     │                         │── 6. Libera CompletableFuture                                 │
     │                         │── 7. Aplica Adaptadores Saída                                 │
     │◄── 8. Resposta HTTP ────│

1. Recebimento e Validação da Sessão

A Engine recebe a requisição HTTP em uma thread virtual dedicada, valida o inicializador, escopo e credenciais de segurança, extrai os parâmetros de entrada e gera o identificador único da sessão (idSessao).

2. Despacho Inicial

A primeira etapa do fluxo é enviada para o barramento de eventos para ser consumida pelo runner correspondente.

3. Registro do Futuro e Suspensão da Thread

Em vez de utilizar Servlets com contexto assíncrono tradicional, a Engine registra uma estrutura de espera baseada em CompletableFuture associada ao idSessao em um mapa concorrente em memória. A thread virtual fica suspensa aguardando a resolução desse futuro ou a ocorrência de um tempo limite (timeout).

4. Execução Distribuída pelos Runners

Os runners consomem os eventos do barramento, executam suas tarefas atômicas (consultas SQL, scripts, chamadas HTTP externas) e devolvem o progresso ao orquestrador.

5. Notificação de Conclusão via PubSub

Quando a última etapa do fluxo é concluída (ou quando ocorre uma interrupção/erro), o orquestrador publica uma mensagem leve no canal PubSub do cache de sessão apontando especificamente para a instância/pod que originou a chamada (inbox:{hostname}).

6. Resolução e Formatação de Saída

O consumidor PubSub da Engine recebe o sinal de conclusão e resolve o CompletableFuture associado àquele idSessao. A thread virtual é acordada, busca o resultado na sessão, aplica os Adaptadores de Saída (definindo cabeçalhos, corpo e status HTTP) e devolve a resposta final ao cliente.

Mecanismos de Timeout

Para evitar o represamento de conexões pendentes em cenários de degradação externa ou fluxos com tempo de execução elevado, a Engine aplica regras rígidas de tempo limite de espera (timeout):

Escopo Público: Timeout padrão curto de 5 segundos. Projetado para garantir alta responsividade em chamadas vindas da web ou dispositivos móveis.
Escopos Interno e Agendador: Timeout padrão estendido de 30 segundos. Acomoda o tempo de processamento de rotinas mais complexas e integrações entre subfluxos.
Tratamento de Excesso de Tempo: Caso o futuro de espera não seja resolvido dentro do tempo limite configurado para o escopo, a Engine remove o registro do mapa concorrente e encerra a conexão de forma limpa, devolvendo uma resposta de erro HTTP 408 Request Timeout ao cliente.

Vantagens da Espera Baseada em PubSub + Threads Virtuais

Escalabilidade de Recursos: O bloqueio leve exercido sobre as threads virtuais do sistema permite suportar milhares de conexões síncronas simultâneas por pod sem causar contenção de threads do sistema operacional.
Eliminação de Polling: A Engine não realiza varreduras perióficas no banco ou no cache para checar se o fluxo terminou. A notificação via PubSub entrega o aviso de término em milissegundos.
Retorno Desacoplado do Barramento de Eventos: O tráfego de retorno do fluxo não é enviado de volta para filas no barramento principal de mensagens, otimizando a largura de banda apenas para o disparo de etapas.