Event-Driven Serverless Architecture on Google Cloud

A short guide to one shape of application: a user submits data, a few steps run on it — often a Gemini call among them — and a result returns to the browser. The work is orchestration, not heavy computation. Every choice below favors three properties — decoupled, stateless, event-driven — and names the service that does each job.

The shape

Keep three concerns apart: what moves the work, what runs it, and where state lives. Confusing them is the usual cause of tangled designs.

Events move the work. Serverless compute runs it and holds nothing between requests. Managed services hold the state. Compute that persists nothing locally can scale to zero, scale out, and survive a restart without losing a request.

What each service is for

Workflows is the orchestrator. It owns the order of steps, calls each service, retries on failure, and can run for up to a year. Its definition is the single source of truth for what happens and in what order. It holds the orchestration state so the workers don't have to.

Cloud Run runs the code. A service answers HTTP and scales to zero. A job runs to completion for batch work. A worker pool pulls from a queue but does not autoscale on its own. Cloud Run functions are the same engine wrapped around a single trigger. Treat any of them as a stateless worker the workflow calls.

Gemini runs through Vertex AI. Call it from a workflow with the Vertex AI connector, or from Cloud Run with the service account's own credentials and no API keys. Inside an orchestration the workflow calls it directly; reach for Cloud Run only when the logic around the call outgrows the workflow language.

Pub/Sub is the asynchronous bus. Publish once, and every subscriber gets its own copy. Use it to fan out to many consumers, to absorb traffic spikes, and to carry your own domain events between services. You already use it indirectly, because Eventarc runs on top of it.