Cloud Run worker pools become generally available for pull-based processing

Google announced general availability of Cloud Run worker pools in an April 10 post describing an Estée Lauder Companies deployment. The announcement positions worker pools for continuously running, pull-based processing rather than request-driven services or run-to-completion jobs.

Queue consumers get their own runtime choice

The launch gives teams a managed place for workers that fetch messages at their own pace. Google also describes private addresses for instances attached to a VPC and discusses its open-source Cloud Run External Metrics Autoscaler, or CREMA, for workload-driven scaling.

The important engineering distinction is how work arrives. A consumer decides when to ask for another message; that can help align concurrency with the capacity of the downstream operation. It does not by itself guarantee message durability, exactly-once effects, or a safe retry policy.

A migration should therefore preserve the queue’s acknowledgement and visibility rules. Moving a consumer into a managed runtime is not a reason to acknowledge before its work is durably complete.

Scale from backlog and service time

Choose an autoscaling signal that represents useful demand. Queue depth alone may be misleading if message costs vary sharply, so include processing duration and the capacity of constrained dependencies in the evaluation.

Test worker termination after an external action but before acknowledgement. The replacement worker needs a way to recognize completed work or repeat it safely. Also test shutdown while the consumer has several messages in flight.

Teams with an HTTP wrapper around long-running consumers now have a more direct deployment option to examine. A good pilot measures end-to-end completion time and recovery behavior, then demonstrates that adding workers improves throughput without overwhelming the database or external service behind the queue.