El servicio responde bien con una petición cada vez. Bajo carga, aumenta la latencia, la base de datos empieza a rechazar conexiones o una variable global mezcla estados. La primera reacción suele ser buscar un número mágico para la concurrencia de Cloud Run.

Ese número no existe. La configuración define cuántas peticiones puede recibir una instancia al mismo tiempo. El valor seguro es el nivel más alto que tu aplicación puede mantener sin superar la CPU, la memoria, el estado compartido o una dependencia limitada. El valor predeterminado de la plataforma es solo un punto de partida.

Esta guía convierte la decisión en un ciclo breve: identifica el cuello de botella, empieza con un límite conservador, crea una revisión, prueba con carga representativa y observa qué falla primero. Los comandos son ilustrativos y no se ejecutaron contra un servicio de Cloud Run en este repositorio. La introducción a Cloud Run explica el modelo de la plataforma antes de este ajuste.

Diagrama que muestra peticiones pasando por un límite de concurrencia de Cloud Run hacia una instancia, con límites de CPU y memoria.

Respuesta corta

  • 80 es el valor predeterminado de la consola, no una recomendación para todas las aplicaciones.
  • Reduce el valor cuando cada petición usa mucha CPU o memoria, o cuando el código no es seguro para ejecutarse a la vez.
  • Los valores altos pueden aprovechar mejor el I/O asíncrono, pero presionan los recursos compartidos y pueden aumentar la latencia.
  • Prueba una revisión cada vez. Observa latencia, errores, instancias y límites externos antes de conservar el cambio.

¿Qué controla la concurrencia de Cloud Run?

En 2026, Google Cloud, "Maximum concurrent requests for services", consultado el 26/08/2026, define la concurrencia máxima por instancia. El valor predeterminado de la consola es 80 y la configuración puede llegar a 1.000. Es un límite de entrada para cada instancia, no una promesa de que se utilizarán todos los huecos.

Si configuras 20, una instancia puede recibir hasta veinte peticiones simultáneas. El servicio puede crear más instancias cuando aumenta la demanda. Si la CPU, la memoria u otro recurso ya está ocupado, Cloud Run puede enviar menos peticiones a esa instancia. El número configurado no reemplaza el límite real del proceso.

Hay tres límites que suelen confundirse:

Límite Qué controla Síntoma al superarlo
Concurrencia de Cloud Run Peticiones por instancia Más espera, instancias o cola
CPU y memoria Trabajo que puede ejecutar una instancia Latencia alta, errores o reinicios
Recursos externos Llamadas a base de datos, caché o API Timeouts, rechazos y reintentos

Un valor alto puede reducir el número de instancias activas cuando el trabajo es principalmente I/O. También puede concentrar más peticiones en un proceso con un pool de conexiones pequeño. Trata la concurrencia como parte del diseño del servicio, no como un ajuste aislado de la consola.

¿Cómo elegir entre una concurrencia baja y una alta?

En 2026, Google Cloud, "General development tips", consultado el 26/08/2026, recomienda probar el servicio bajo carga e iterar hasta encontrar la concurrencia máxima estable. La misma documentación describe el intercambio: los límites bajos reducen la competencia dentro de una instancia, mientras que los altos pueden mejorar el rendimiento por instancia.

Empieza por la unidad de trabajo más pesada de la ruta. Una API que espera a otro servicio puede mantener disponible JavaScript mientras espera I/O. Una ruta que comprime archivos, transforma imágenes o calcula embeddings puede usar CPU y memoria durante casi toda la petición. No deberían heredar el mismo límite por defecto.

Haz estas preguntas antes de cambiar el ajuste:

  • ¿Cada petición cabe en la memoria disponible cuando llegan varias juntas?
  • ¿La aplicación usa objetos globales mutables que las peticiones pueden cambiar?
  • ¿El pool de conexiones de la base de datos soporta las peticiones de una instancia?
  • ¿Un proveedor externo impone un límite de llamadas o responde lentamente?
  • ¿Esta ruta necesita baja latencia o más rendimiento por instancia?

Si una respuesta es "no", reduce la concurrencia o separa primero la ruta pesada. Si todas son "sí", prueba un valor mayor y observa el servicio. El objetivo no es alcanzar el máximo de la plataforma. Es evitar que una instancia se convierta en un cuello de botella concentrado.

El límite más importante puede estar fuera de Cloud Run. Si una instancia recibe más trabajo del que su pool de conexiones o la API externa puede atender, subir la concurrencia solo cambia instancias por esperas y reintentos. El ajuste debe respetar el recurso compartido más estrecho del recorrido.

¿Qué cambia con Node.js?

En 2026, Node.js, "Overview of Blocking vs Non-Blocking", consultado el 26/08/2026, describe la ejecución de JavaScript de Node.js como single-threaded y explica que el I/O asíncrono permite que el event loop continúe. Por eso una concurrencia alta puede funcionar al esperar la red, mientras el código bloqueante sigue ocupando el proceso.

Cloud Run no crea un hilo de JavaScript nuevo para cada petición. El proceso gestiona trabajo concurrente cuando el código devuelve el control al event loop. Una función asíncrona puede avanzar mientras espera una respuesta. Una función que hace trabajo síncrono pesado impide que avancen las demás peticiones, aunque el límite de la plataforma sea alto.

Esto cambia lo que debes revisar en una prueba. No compares solo peticiones por segundo. Comprueba si la latencia sube cuando las peticiones compiten por el event loop, si crece el heap y si se acumulan las llamadas externas. Si una ruta depende de estado global, elimina la mutabilidad o usa un límite menor hasta demostrar que el acceso es seguro.

Un ejemplo sencillo es un cliente con un pool de conexiones pequeño. El servicio puede recibir veinte peticiones, pero solo algunas pueden hablar con la base de datos al mismo tiempo. Las demás esperan dentro de la instancia. Puede ser aceptable si la espera cabe en el objetivo de latencia y la memoria permanece controlada.

¿Cómo aplicar un valor sin convertir el despliegue en una apuesta?

En 2026, Google Cloud, "Set maximum concurrent requests per instance", consultado el 26/08/2026, documenta gcloud run services update SERVICE --concurrency CONCURRENCY e indica que cambiar el ajuste crea una nueva revisión. Usa ese comportamiento para comparar configuraciones aisladas.

Un punto de partida conservador puede ser este:

gcloud run services update SERVICE --concurrency 8

El 8 aparece en la orientación de Google como ejemplo de un valor bajo con el que empezar y después subir. No es una respuesta universal. Para volver al valor predeterminado, la misma referencia documenta:

gcloud run services update SERVICE --concurrency default

Después de cada cambio, espera a que la revisión esté lista y compara el mismo escenario de tráfico. No cambies a la vez concurrencia, CPU, memoria, pool de base de datos y timeout. Si mueves varias palancas, pierdes la capacidad de explicar el efecto.

Confirma también que la aplicación acepta la simultaneidad elegida. Google Cloud recomienda que la concurrencia de Cloud Run sea igual o menor que cualquier límite definido en el código. Así la plataforma no acepta trabajo que un semáforo interno no puede organizar.

¿Cómo probar la concurrencia de Cloud Run?

En 2026, Google Cloud, "General development tips", consultado el 26/08/2026, recomienda herramientas de prueba de carga con concurrencia configurable y repetir el proceso hasta encontrar el valor estable más alto. Un despliegue correcto solo demuestra que la revisión arrancó. No demuestra que el servicio soporte el tráfico esperado.

Usa una prueba por etapas:

  1. Elige una ruta representativa y una entrada con el coste normal de producción.
  2. Registra una línea base de latencia, errores, CPU y memoria.
  3. Envía carga concurrente controlada a la revisión sin mezclar otros cambios.
  4. Observa también el pool de base de datos, los límites de API, las colas y los reintentos externos.
  5. Repite con un límite más alto o más bajo hasta que aparezca la primera señal de inestabilidad.
  6. Mantén un margen por debajo de ese punto y repite después de cambios importantes.

La primera señal puede ser una cola más larga, no un error HTTP. También puede ser un pequeño aumento de latencia que se multiplica cuando una dependencia se ralentiza. Registra qué recurso cambió primero. Esa observación vale más que decir solo que la prueba "pasó".

Si el servicio también ejecuta trabajo continuo, la comparación entre Services, Jobs y worker pools de Cloud Run ayuda a separar la elección de ejecución de la concurrencia HTTP.

No hay un benchmark de un servicio de este repositorio que podamos publicar. El procedimiento es un método de verificación, no un resultado medido. Cada equipo necesita sus propias rutas, datos, límites de dependencias y objetivo de latencia.

¿Qué señales piden una concurrencia menor?

En 2026, Google Cloud, "Maximum concurrent requests for services", consultado el 26/08/2026, enumera la CPU o la memoria casi llenas y el código incapaz de gestionar peticiones simultáneas como razones para considerar una concurrencia de 1. El coste es que pueden hacer falta más instancias para el mismo pico de tráfico.

Reduce el límite cuando observes cualquiera de estas situaciones:

  • una petición usa casi toda la CPU o memoria de la instancia;
  • una variable global, caché local o cliente no es seguro para acceso concurrente;
  • la base de datos empieza a rechazar conexiones cuando la instancia se llena;
  • las llamadas externas acumulan timeouts y reintentos. Para trabajos que se ejecutan de nuevo, consulta cómo evitar duplicados cuando Cloud Run Jobs reintenta;
  • los picos vuelven lenta cada instancia antes de que aparezcan nuevas instancias.

La concurrencia 1 puede proteger el servicio mientras corriges la disputa, pero no debería ocultar su causa. Google Cloud también advierte que el valor puede ralentizar el escalado porque deben iniciar más instancias durante un pico. Si la ruta usa I/O asíncrono y estado seguro, un valor mayor puede ofrecer un equilibrio mejor.

¿Qué debes observar después del despliegue?

En 2026, Google Cloud, "About instance autoscaling in Cloud Run services", consultado el 26/08/2026, describe la CPU y la concurrencia de peticiones como señales de escalado y usa objetivos predeterminados de 60% para ambas. Esos objetivos describen la plataforma, no el SLO de tu aplicación.

Después del despliegue, observa cuatro grupos de señales:

Grupo Pregunta
Usuario ¿La latencia y los errores siguen dentro del objetivo de la ruta?
Instancia ¿CPU, memoria y peticiones activas suben juntas, o un recurso se satura primero?
Dependencias ¿La base de datos, caché, cola o API externa recibe más presión por instancia?
Escalado ¿El servicio crea instancias a tiempo o las peticiones esperan?

No concluyas que un ajuste es mejor solo porque redujo el número de instancias. Menos instancias pueden significar más espera dentro de cada proceso. Tampoco asumas que el ajuste menor es más barato. Google Cloud indica que bajar el límite puede aumentar o reducir el tiempo facturable según si la menor latencia compensa las instancias adicionales.

Cuando cambie el valor, compara ventanas equivalentes y registra la revisión, la configuración, el tipo de carga y los límites externos. Sin ese registro, el equipo puede atribuir a la concurrencia un efecto que en realidad provino del código, del tráfico o de una dependencia.

Preguntas frecuentes

¿El valor predeterminado 80 es seguro para una API de Node.js?

No necesariamente. 80 es el valor predeterminado de la consola documentado por Google Cloud, pero la aplicación puede tener límites menores de CPU, memoria, estado global o pool de base de datos. Empieza con un valor que el código pueda soportar, prueba bajo carga y súbelo hasta encontrar el ajuste estable más alto.

¿La concurrencia 1 elimina las condiciones de carrera?

Reduce la concurrencia por instancia, pero no elimina todas las carreras. Cloud Run puede ejecutar varias instancias y una dependencia externa aún puede recibir operaciones simultáneas. Usa el ajuste como protección, no como sustituto de operaciones idempotentes, transacciones o estado compartido seguro.

¿Cómo sé si debo subir o bajar la concurrencia?

Súbela solo mientras la instancia permanezca estable y los recursos externos estén dentro de sus límites. Bájala cuando CPU, memoria, latencia, errores o conexiones se saturen primero. Google Cloud recomienda probar bajo carga e iterar. No conviertas 80, 8 o 1 en una regla sin observar tu ruta.

Conclusión

Elegir la concurrencia de Cloud Run significa encontrar el límite de todo el recorrido, no aceptar el valor predeterminado sin investigar. Identifica el recurso más estrecho. Después crea una revisión con un valor conservador, cambia una variable cada vez y observa la aplicación junto con sus dependencias.

En un servicio Node.js con I/O asíncrono y estado seguro, un valor mayor puede aprovechar mejor cada instancia. Para una ruta pesada o un estado compartido inseguro, un valor menor puede proteger la latencia mientras corriges el diseño. El número final debe ser una decisión registrada que otra persona pueda verificar.

Fuentes consultadas

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