Serviços que somam ao Bedrock IV: canais e borda

A regra que resolve a maior parte dos casos

Síncrono e curto: borda HTTP simples com função. Síncrono com resposta longa: conexão persistente ou resposta em fluxo. Assíncrono: evento com fila e notificação do desfecho. Comece por aí e só troque quando um limite concreto empurrar — mas escolha antes de construir, porque trocar depois é refazer a camada.

Em voz, o orçamento de latência é somado

Transcrição, retrieval, inferência, guardrail e síntese acontecem em série, e o usuário sente a soma. É por isso que o caso público de contact center por voz com latência na casa de poucos segundos impressiona: cada etapa precisou caber num orçamento apertado. Regra prática: meça o tempo de cada etapa separadamente desde o primeiro dia, porque quando o total estourar você vai precisar saber quem consumiu o quê.

A divisão de trabalho entre Lex e Bedrock

Campo com formato conhecido não deveria passar por modelo generativo: número de pedido, CPF, data e valor têm validação determinística, e errar a coleta contamina tudo depois. Deixe o Lex coletar e validar o estruturado, e o Bedrock responder o que é aberto. Além de mais barato, é mais confiável — e dá ao usuário a chance de corrigir um dígito antes de a conversa seguir.

Canal assíncrono muda a arquitetura, não só o transporte

Quando o canal é e-mail ou notificação, o timeout de borda deixa de existir como problema — e isso libera decisões melhores: você pode usar batch e pagar cerca de metade, pode escalar para o tier de raciocínio sem preocupação com latência, e pode enfileirar picos sem que ninguém perceba. Vale perguntar em todo projeto se o caso de uso realmente exige resposta imediata; com frequência, exige apenas resposta confiável.

O erro nº 1 desta camada: timeout na borda

Uma resposta de LLM com raciocínio pode levar dezenas de segundos, e vários caminhos de borda cortam a conexão antes disso. O sintoma é cruel: funciona nos testes com perguntas curtas e falha em produção justamente nas perguntas difíceis, que são as que importam. As saídas são três — streaming (o primeiro token chega em menos de um segundo e a conexão fica viva), assíncrono com notificação, ou uma borda sem esse teto. Escolha antes de construir, porque trocar depois é refazer a camada inteira.

Detalhes que só aparecem em produção

Conexão fechada no meio da geração precisa interromper o laço — sem isso você paga a resposta inteira para uma aba que já foi embora, e em escala isso é dinheiro real. O registro da conexão precisa de expiração automática, ou a tabela acumula conexões mortas. E reconexão tem que ser tratada no cliente: rede móvel derruba WebSocket o tempo todo, e o usuário não pode perder o turno por causa disso.

O CDN não resolve latência de IA — e ainda pode enganar

É comum alguém propor CloudFront esperando acelerar as respostas. Ele acelera o estático, o handshake e a rota até a origem, mas a inferência acontece atrás de tudo isso e não é cacheável: a mesma pergunta gera resposta nova. Onde o cache de borda realmente entra é sobre resposta materializada de pergunta frequente — que é outra alavanca, do playbook de custo, não da camada de rede.

A coluna do meio é a que decide

Repare que a escolha da borda é quase inteiramente determinada pela segunda coluna. Responder "preciso de streaming?" antes de qualquer outra discussão elimina metade das opções e evita a conversa improdutiva sobre preferência de stack. E a resposta é sim sempre que houver humano esperando por texto longo.