Como escolher a concorrência no Cloud Run

O serviço responde bem com uma requisição por vez. Sob carga, a latência sobe, o banco começa a recusar conexões ou uma variável global passa a misturar estados. A primeira reação costuma ser procurar um número mágico para a concorrência do Cloud Run.

Esse número não existe. A configuração define quantas requisições uma instância pode receber ao mesmo tempo. O valor seguro é o maior que sua aplicação sustenta sem ultrapassar CPU, memória, estado compartilhado ou qualquer dependência limitada. O padrão da plataforma é apenas o ponto de partida.

Este guia transforma essa escolha em um ciclo curto: identificar o gargalo, começar com um limite conservador, criar uma revisão, testar com carga representativa e observar o que quebra primeiro. Os comandos são ilustrativos e não foram executados em um serviço Cloud Run deste repositório. A introdução ao Google Cloud Run cobre o modelo geral da plataforma antes deste ajuste.

Resposta curta

• 80 é o padrão de concorrência do console, não uma recomendação para toda aplicação.
• Diminua o valor quando cada requisição usa muita CPU ou memória, ou quando o código não é seguro para execução simultânea.
• Valores maiores podem aproveitar melhor I/O assíncrono, mas pressionam recursos compartilhados e podem aumentar a latência.
• Teste uma revisão por vez. Observe latência, erros, instâncias e limites downstream antes de manter a mudança.

O que a concorrência do Cloud Run controla?

Em 2026, a documentação Google Cloud, "Maximum concurrent requests for services", consultada em 26/08/2026, define a concorrência máxima por instância. O console usa 80 como padrão e a configuração pode chegar a 1.000. Isso é um teto de entrada para cada instância, não uma promessa de que todos os slots serão usados.

Se você configura 20, uma instância pode receber até vinte requisições simultâneas. O serviço pode criar outras instâncias quando a demanda cresce. Se CPU, memória ou outro recurso já estiver ocupado, o Cloud Run pode enviar menos requisições para aquela instância. O número configurado não substitui o limite real do processo.

A diferença importa porque três limites costumam ser confundidos:

Uma configuração alta pode reduzir a quantidade de instâncias ativas quando o trabalho é principalmente I/O. Ela também pode concentrar mais requisições em um processo que usa uma piscina pequena de conexões. Por isso, trate concorrência como parte do desenho do serviço, não como um ajuste isolado no console.

Como decidir entre concorrência baixa e alta?

Em 2026, Google Cloud, "General development tips", consultado em 26/08/2026, recomenda testar o serviço e iterar até encontrar a concorrência máxima estável. A mesma documentação resume o trade-off: limites menores reduzem a disputa dentro da instância, enquanto limites maiores podem melhorar o throughput por instância.

Comece pela unidade de trabalho mais pesada da rota. Uma API que espera um serviço externo pode manter o JavaScript livre durante o I/O. Uma rota que comprime arquivos, transforma imagens ou calcula embeddings pode ocupar CPU e memória durante quase toda a requisição. As duas rotas podem viver no mesmo serviço, mas não têm o mesmo limite seguro.

Use estas perguntas antes de mudar a configuração:

• Cada requisição cabe na memória disponível quando várias chegam juntas?
• A aplicação usa objetos globais mutáveis que duas requisições podem alterar?
• O pool de conexões do banco comporta o número de requisições de uma instância?
• Um provedor externo impõe limite de chamadas ou responde lentamente?
• O serviço precisa de baixa latência ou de maior throughput por instância?

Se uma resposta for "não", a primeira tentativa deve baixar a concorrência ou separar a rota pesada. Se todas forem "sim", você pode testar um valor maior, mas ainda precisa observar o comportamento sob carga. O objetivo não é atingir o teto da plataforma. É evitar que a instância vire um gargalo concentrado.

O limite mais importante pode estar fora do Cloud Run. Se uma instância recebe mais requisições do que o pool de conexões ou a API downstream suporta, aumentar a concorrência apenas troca instâncias por espera e retries. O valor precisa respeitar o recurso compartilhado mais estreito do caminho.

O que o Node.js muda nessa escolha?

Em 2026, a documentação Node.js, "Overview of Blocking vs Non-Blocking", consultada em 26/08/2026, descreve a execução JavaScript do Node.js como single-threaded e explica que I/O assíncrono deixa o event loop continuar. Portanto, concorrência alta pode funcionar para espera de rede, mas código bloqueante ainda ocupa o processo.

O Cloud Run não cria uma thread JavaScript nova para cada requisição. O processo recebe trabalho concorrente conforme o código devolve o controle ao event loop. Uma função que usa APIs assíncronas pode progredir enquanto espera uma resposta. Uma função que faz trabalho síncrono pesado impede as outras de avançar, mesmo que o limite da plataforma seja alto.

Isso muda a leitura dos testes. Não compare apenas requisições por segundo. Verifique se a latência aumenta quando há disputa pelo event loop, se o heap cresce durante requisições simultâneas e se as chamadas externas se acumulam. Se a rota depende de estado global, remova a mutabilidade ou escolha um limite baixo até provar que o acesso é seguro.

Um exemplo simples de risco é um cliente criado com um pool pequeno. O serviço pode receber vinte requisições, mas apenas algumas conseguem falar com o banco ao mesmo tempo. As demais ficam aguardando dentro da instância. Isso pode ser aceitável, desde que a espera esteja dentro do objetivo de latência e não consuma memória sem limite.

Como aplicar um valor sem transformar o deploy em aposta?

Em 2026, Google Cloud, "Set maximum concurrent requests per instance", consultado em 26/08/2026, documenta gcloud run services update SERVICE --concurrency CONCURRENCY e informa que alterar a configuração cria uma nova revisão. Use esse comportamento para comparar configurações isoladas.

Um ponto de partida conservador pode ser aplicado assim:

gcloud run services update SERVICE --concurrency 8

O 8 aparece na orientação da própria documentação como um valor baixo para começar e subir depois. Ele não é uma resposta universal. Para voltar ao padrão, a mesma referência documenta:

gcloud run services update SERVICE --concurrency default

Depois de cada alteração, espere a revisão estar pronta e compare o mesmo cenário de tráfego. Não mude concorrência, CPU, memória, pool do banco e timeout ao mesmo tempo. Se várias alavancas mudarem, você perde a capacidade de explicar qual alteração produziu o efeito.

Também confirme que o código da aplicação aceita a simultaneidade escolhida. A documentação do Google Cloud recomenda que a configuração do Cloud Run seja igual ou menor que qualquer limite de concorrência definido no próprio código. Esse detalhe evita que a plataforma aceite trabalho que um semáforo interno não consegue organizar.

Como testar a concorrência do Cloud Run?

Em 2026, Google Cloud, "General development tips", consultado em 26/08/2026, orienta usar ferramentas de teste de carga com concorrência configurável e repetir o processo até encontrar o maior valor estável. Uma implantação concluída só prova que a revisão iniciou; não prova que ela aguenta o tráfego esperado.

Faça o teste em etapas:

1. Escolha uma rota representativa e uma entrada que tenha o custo comum da produção.
2. Registre uma linha de base com latência, taxa de erro, uso de CPU e memória.
3. Envie carga concorrente controlada para a revisão, sem misturar outras mudanças.
4. Observe também pool de banco, limites de API, filas e retries downstream.
5. Repita com um limite maior ou menor até encontrar o primeiro sinal de instabilidade.
6. Mantenha uma margem abaixo desse ponto e repita o teste depois de mudanças relevantes.

O primeiro sinal pode ser uma fila maior, e não um erro HTTP. Pode ser também uma pequena subida de latência que multiplica quando a dependência externa entra em modo lento. Registre qual recurso mudou primeiro. Essa observação é mais útil do que dizer apenas que a carga "passou".

Se o serviço também executa trabalho contínuo, a comparação entre Service, Job e worker pool no Cloud Run ajuda a separar a escolha de execução da escolha de concorrência HTTP.

Não há benchmark de um serviço deste repositório para publicar aqui. O procedimento acima é um método de verificação, não um resultado medido. Cada equipe precisa usar suas próprias rotas, dados, limites de dependência e objetivo de latência.

Quais sinais pedem uma concorrência menor?

Em 2026, Google Cloud, "Maximum concurrent requests for services", consultado em 26/08/2026, lista CPU ou memória quase totalmente ocupadas e código que não suporta requisições simultâneas como motivos para considerar concorrência 1. O custo dessa escolha é criar mais instâncias para atender o mesmo pico.

Baixe o limite quando observar qualquer uma destas situações:

• uma requisição usa quase toda a CPU ou memória da instância;
• uma variável global, cache local ou cliente não é seguro para acesso concorrente;
• o banco começa a rejeitar conexões quando a instância fica cheia;
• chamadas downstream acumulam timeout e retry. Para trabalhos com reexecução, veja também como evitar duplicação nos retries de Cloud Run Jobs;
• picos de tráfego deixam cada instância lenta antes de novas instâncias surgirem.

Concorrência 1 pode ser uma boa proteção temporária enquanto você corrige o código, mas não deve esconder o motivo da disputa. O próprio Google Cloud alerta que o valor pode piorar a velocidade de escala porque muitas instâncias precisam iniciar para atender um pico. Se a rota usa I/O assíncrono e tem estado seguro, um valor maior pode produzir melhor equilíbrio.

O que observar depois do deploy?

Em 2026, Google Cloud, "About instance autoscaling in Cloud Run services", consultado em 26/08/2026, descreve CPU e concorrência de requisições como sinais de autoscaling e usa alvos padrão de 60% para ambos. Esses alvos pertencem ao comportamento da plataforma, não são um SLO para a sua aplicação.

Após o deploy, observe quatro grupos de sinais:

Não conclua que uma configuração é melhor só porque reduziu a quantidade de instâncias. Menos instâncias podem significar mais espera dentro de cada processo. Também não conclua que a configuração menor é mais barata. O Google Cloud observa que a redução pode aumentar ou diminuir o tempo faturável, dependendo de a latência cair o bastante para compensar as instâncias extras.

Quando o valor muda, compare janelas equivalentes e registre a revisão, a configuração, o tipo de carga e os limites downstream. Sem esse registro, a equipe pode atribuir à concorrência um efeito que veio de uma mudança de código, tráfego ou dependência.

Perguntas frequentes

O valor padrão 80 é seguro para uma API Node.js?

Não necessariamente. 80 é o padrão do console documentado pelo Google Cloud, mas a aplicação pode ter CPU, memória, estado global ou pool de banco menores que esse limite. Comece por uma configuração que o código suporte, teste sob carga e suba até o maior valor estável.

Concorrência 1 elimina problemas de corrida?

Ela reduz a simultaneidade por instância, mas não corrige toda corrida. O Cloud Run pode executar várias instâncias, e uma dependência externa ainda pode receber operações concorrentes. Use o limite como proteção, não como substituto para operações idempotentes, transações ou estado compartilhado seguro.

Como saber se devo aumentar ou diminuir a concorrência?

Aumente apenas quando a instância permanece estável e o recurso downstream continua dentro do limite. Diminua quando CPU, memória, latência, erros ou conexões saturarem primeiro. A documentação do Google Cloud recomenda load test e iteração. Não transforme 80, 8 ou 1 em regra sem observar a sua rota.

Conclusão

Escolher a concorrência no Cloud Run é encontrar o limite do caminho completo, não aceitar o número padrão sem investigação. Comece identificando o recurso mais estreito. Em seguida, crie uma revisão com um valor conservador, teste uma variável por vez e observe a aplicação junto das dependências.

Para um serviço Node.js com I/O assíncrono e estado seguro, um valor maior pode aproveitar melhor cada instância. Para uma rota pesada ou não segura para simultaneidade, um valor menor pode proteger a latência enquanto o desenho é corrigido. O número final deve ser uma decisão registrada e verificável.

Fontes consultadas

• Google Cloud, "Maximum concurrent requests for services", retrieved 2026-08-26, https://docs.cloud.google.com/run/docs/about-concurrency
• Google Cloud, "General development tips", retrieved 2026-08-26, https://docs.cloud.google.com/run/docs/tips/general
• Google Cloud, "Set maximum concurrent requests per instance", retrieved 2026-08-26, https://docs.cloud.google.com/run/docs/configuring/concurrency?hl=en
• Google Cloud, "About instance autoscaling in Cloud Run services", retrieved 2026-08-26, https://docs.cloud.google.com/run/docs/about-instance-autoscaling
• Node.js, "Overview of Blocking vs Non-Blocking", retrieved 2026-08-26, https://nodejs.org/learn/asynchronous-work/overview-of-blocking-vs-non-blocking