Follow the work, not just the container
CloudMart contains an HTTP API and a queue-consuming worker. They may share an image or dependencies, but they have different execution lifecycles. This proposed Google Cloud architecture uses the project to explain that distinction. The project’s verified flows remain the isolated local application and the fictional browser demo.
An HTTP service is one kind of runtime
Cloud Run services handle HTTP requests with stateless container instances. Cloud Run also distinguishes run-to-completion jobs, worker pools and instance workloads. Select the resource that matches the process, and check its current availability and constraints before planning delivery.
The FastAPI entry point fits the HTTP-service question. A worker that continuously polls a Redis queue needs a separate lifecycle decision. It should not be assumed to remain active merely because an HTTP endpoint was deployed successfully.
flowchart TB
B[Browser request] --> A[HTTP API service]
A --> D[(Durable order records)]
A --> Q[Queue]
Q --> W[Separately managed worker runtime]
W --> DConfiguration is part of the deployment contract
The container must receive the environment it expects. Cloud Run provides environment-variable configuration for services, including reserved variables. A production adaptation should document each application setting, how secrets are supplied and which values vary by environment. A local example file is documentation, not a production credential bundle.
Keep durable state outside a replaceable instance
Order history must survive an application restart or replacement. The API and worker need a shared, persistent database with deliberate access rules. The queue also needs an agreed durability and retry model. Choosing a managed PostgreSQL or Redis-compatible service requires compatibility and restore validation; it does not happen automatically when the API is containerized.
Think about acknowledgement and retry together
When a worker has updated the order but fails before acknowledging the queue item, a retry may repeat the operation. Define the expected result for that sequence. A useful production design makes processing idempotent or makes repeated work detectable and reviewable.
receive work -> validate current state -> apply transition
-> record outcome -> acknowledge workTest the execution boundaries
- Restart the API independently from the worker.
- Submit an order while the worker is unavailable.
- Resume the worker and verify the stored outcome.
- Exercise a repeated queue item and inspect the resulting record.
- Check the documented restore procedure in an isolated environment.
The transferable idea is to match a runtime to its work. The cloud design then needs the application-specific checks that prove the pieces behave correctly together.
Try the CloudMart order pipeline