Streaming de Respostas com Lambda: Precificação em Tempo Real

O modelo clássico de invocação Lambda é síncrono e atômico: a função executa, acumula toda a resposta em memória, e só então o runtime serializa o payload de volta ao invocador. Para a maioria das APIs REST isso é irrelevante, mas para um motor de precificação que precisa transmitir cotações incrementais (bid/ask por instrumento, Greeks calculados progressivamente, ou um bundle de 50 instrumentos correlacionados), esse modelo força o cliente a esperar o pior caso antes de receber qualquer dado útil.

O problema se agrava quando você considera a composição típica de um engine de precificação: consulta a um feed de mercado (latência variável), cálculo de modelo (CPU-bound, potencialmente 20-80 ms por instrumento), e serialização do resultado. Com o modelo antigo, um bundle de 50 instrumentos com P99 de 120 ms por instrumento resulta em uma resposta que só chega após ~6 segundos no pior caso, inaceitável para qualquer interface de trading ou sistema de margem em tempo real.

A alternativa pré-streaming era WebSockets via API Gateway, que resolve a latência mas introduz estado de conexão, gerenciamento de sessão, e um modelo de cobrança por minuto de conexão que escala mal com picos de mercado. O outro caminho era migrar para containers ECS/EKS com SSE (Server-Sent Events), perdendo a elasticidade e o modelo operacional serverless. Lambda response streaming é a terceira via, e ela tem um preço arquitetural que precisa ser entendido antes de ser adotado.

Quando você configura InvokeMode: RESPONSE_STREAM em uma Function URL, o runtime Lambda substitui o buffer de resposta por um pipe bidirecional entre o handler e o serviço de streaming interno da AWS. No Node.js, isso se manifesta como um awslambda.streamifyResponse wrapper que expõe um responseStream writeable; em Python, o padrão é similar via lambda_streaming. O runtime mantém a conexão HTTP/2 aberta com o invocador enquanto o stream não é fechado ou enquanto o timeout da função não é atingido.

O detalhe crítico que a documentação suaviza: o primeiro byte deve ser enviado dentro do timeout de resposta inicial (padrão 15 segundos para Function URLs, não configurável separadamente do timeout da função). Se a função demora para iniciar o stream, por exemplo, aguardando uma consulta de banco de dados antes de começar a escrever, o comportamento é idêntico ao modelo síncrono do ponto de vista de latência percebida pelo cliente.

O throughput máximo de streaming é de 20 MB por invocação com um payload de resposta máximo de 20 MB (versus 6 MB no modelo síncrono via API Gateway). Para precificação, isso é mais que suficiente, um bundle de 500 instrumentos com 200 bytes por cotação é 100 KB. O gargalo real é outro: backpressure. Se o cliente consome chunks mais devagar do que a função os produz, o buffer interno do runtime pode se encher, causando bloqueio no write() do handler, o que, em Node.js, significa que o event loop da função fica bloqueado até o buffer drenar. Em Python com threads, o comportamento é diferente mas igualmente traiçoeiro.

A configuração de memória impacta diretamente a CPU disponível para o cálculo do modelo de precificação: em arm64 (Graviton2), 1769 MB é o ponto de inflexão onde você obtém 1 vCPU completo. Abaixo disso, você está em fração de CPU e o cálculo de Greeks ou Monte Carlo vai dominar sua latência.

Este é o ponto onde a maioria dos designs de precificação com streaming falha silenciosamente. Em um sistema financeiro, cada cotação gerada precisa ser auditável: quem pediu, quando, com quais parâmetros de mercado, e qual foi o resultado. Com o modelo síncrono, a auditoria é simples, você loga a resposta completa antes de retorná-la. Com streaming, a resposta é um fluxo de chunks que pode ser interrompido em qualquer ponto por timeout, erro de rede, ou cancelamento pelo cliente.

O padrão que adoto em produção é o quote correlation ID com escrita assíncrona em DynamoDB. Antes de iniciar o stream, a função gera um quoteId (UUID v7, ordenável por tempo, útil para queries de auditoria) e escreve um item inicial no DynamoDB com status STREAMING e TTL de 24 horas. Cada chunk enviado inclui o quoteId no cabeçalho ou no envelope JSON. Ao fechar o stream com sucesso, a função atualiza o item para COMPLETE com o hash SHA-256 do payload concatenado. Se a função termina sem fechar o stream (timeout, erro não tratado), o item permanece em STREAMING, o que é detectável por um processo de reconciliação.

A escrita no DynamoDB deve ser assíncrona em relação ao stream principal, use Promise.allSettled em Node.js ou asyncio.gather em Python para não bloquear o caminho crítico. A tabela de auditoria deve ter quoteId como partition key e timestamp como sort key, com um GSI em clientId + timestamp para queries de auditoria por cliente. Provisioned capacity com DAX não faz sentido aqui, use on-demand com write sharding se você tiver picos de mercado que gerem mais de 1000 cotações/segundo por instrumento.

Um detalhe de segurança frequentemente ignorado: o quoteId não deve ser gerado pelo cliente. Se o cliente controla o ID, você tem um vetor de replay attack onde um cliente pode referenciar uma cotação de outro. Gere server-side, assine com KMS se a regulação exigir não-repúdio.

Function URLs com streaming suportam dois modos de autenticação: AWS_IAM e NONE. Para precificação financeira, NONE é inaceitável mesmo com um authorizer customizado na frente, use AWS_IAM com SigV4 para clientes internos (serviços AWS, sistemas on-premise via PrivateLink) e implemente um Lambda Authorizer com JWT RS256 para clientes externos via CloudFront + WAF.

O WAF é não-negociável em produção financeira. Configure regras específicas para o endpoint de streaming: rate limiting por clientId (extraído do JWT claim no header customizado), bloqueio de requests sem Content-Type: application/json, e uma regra de tamanho máximo de body de 8 KB para o request (o payload de entrada de uma consulta de precificação não deve exceder isso). O WAF com CloudFront adiciona ~1-3 ms de latência mas protege contra DDoS volumétrico e scraping de cotações.

Para o dado em trânsito, TLS 1.3 é obrigatório: Function URLs suportam isso nativamente. Para dados em repouso no DynamoDB de auditoria, use KMS Customer Managed Keys (CMK) com rotação automática anual e uma key policy que restrinja kms:Decrypt apenas ao role da função de auditoria e ao role de compliance. Separe as CMKs por ambiente (dev/staging/prod), isso parece óbvio mas é frequentemente ignorado em sistemas que crescem rápido.

Um aspecto de governança que vai além da segurança técnica: data lineage de cotações. Reguladores como CVM (Brasil) e SEC (EUA) podem exigir rastreabilidade de qual versão do modelo de precificação gerou uma cotação específica. Inclua no envelope de cada chunk o hash do artefato de deployment (disponível via AWS_LAMBDA_FUNCTION_VERSION e o SHA do container image) e o timestamp do feed de mercado utilizado. Isso transforma cada cotação em um artefato auditável com proveniência completa.

Observabilidade em sistemas de streaming é fundamentalmente diferente de APIs síncronas porque uma única invocação pode ter múltiplos pontos de falha e latências parciais relevantes. As métricas padrão do CloudWatch (Duration, Errors, Throttles) são necessárias mas insuficientes.

O que instrumentar especificamente para streaming de precificação:

Latência por chunk: use CloudWatch EMF (Embedded Metric Format) para emitir uma métrica customizada a cada chunk enviado, com dimensões instrumentId e bundleId. Isso permite identificar quais instrumentos são sistematicamente lentos, geralmente aqueles que dependem de feeds com maior latência ou modelos mais complexos.

Chunks enviados vs. chunks esperados: ao fechar o stream, emita a razão chunksDelivered / chunksExpected. Uma razão menor que 1.0 indica streams truncados, por timeout, erro, ou cancelamento do cliente. Em produção financeira, uma taxa de truncamento acima de 0.1% merece investigação imediata.

Distribuição de TTFB de negócio: o tempo entre o início da invocação e o primeiro chunk com dados de preço válidos. Esta é a métrica que correlaciona com satisfação do usuário e com SLOs de trading. Target: P99 < 100 ms com provisioned concurrency.

Cold start rate: com provisioned concurrency, deve ser 0% em condições normais. Um spike de cold starts indica que o Auto Scaling não acompanhou um pico de demanda, configure alarmes em InitDuration > 0 para qualquer invocação.

Para tracing distribuído, use o OTEL Lambda Layer (disponível como extensão gerenciada) com propagação de traceId no envelope de cada chunk. Isso permite correlacionar o span da função com o span do cliente, criando um trace end-to-end que inclui o tempo de consumo de cada chunk pelo cliente, informação impossível de obter sem instrumentação explícita.