agents/gcp_solution_architecture_agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

decomposer: generate deliverable files for Discover and structure the solution's functional requirements, non-functional requirements, constraints, assumptions, and open questions without selecting cloud products.; Select Google Cloud products from the confirmed requirements and produce the solution architecture, Mermaid diagram, architecture description, and Terraform infrastructure-as-code.; Validate the Terraform infrastructure and architecture artifacts without deploying resources by running formatting checks, Terraform validation, and a dry-run or plan-oriented deployment check.; Package the approved requirements, architecture, Mermaid diagram, Terraform IaC, and validation results into solution-architecture-guide.md in the gcp_solution_architecture_agent repository.; Verify that the gcp_solution_architecture_agent repository contains the packaged solution-architecture-guide.md with the approved workflow outputs.; Verify that the repository is derived from the workflow_agent template and implements the complete four-phase Google Cloud solution architecture workflow alongside the packaged guide.; Publish the verified gcp_solution_architecture_agent repository with its completed workflow implementation and solution architecture guide.; Verify that the published repository revision contains the completed workflow implementation and solution architecture guide.

Browse Source
This commit is contained in:
demo-bot
2026-09-01 19:50:17 +00:00
parent fd46d0240f
commit bf7ffe8c02
10 changed files with 295 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
architecture.md
View File

@@ -1,7 +1,44 @@
# Architecture description
# Steps 1–2 — selected architecture and validation design
The design is a regional, event-driven ingestion path. An authenticated producer calls a Cloud Run service. The service performs lightweight schema validation, writes the original payload to a retained Cloud Storage bucket, and publishes an event envelope to Pub/Sub. A separate Cloud Run worker consumes the subscription and invokes downstream systems. At-least-once delivery is intentional: the worker must use an event ID as an idempotency key and acknowledge only after durable processing.
## Selected Google Cloud products
Cloud Run provides independently scalable HTTPS ingress and worker execution without managing servers. Pub/Sub separates producer latency from consumer capacity and provides retry behavior. Cloud Storage is the replay and audit boundary, with uniform bucket-level access and a lifecycle rule. Artifact Registry is the controlled source for externally built container images. Cloud Logging and Cloud Monitoring provide centralized operational signals; alert policies can be added when SLO thresholds are agreed.
- Cloud Run for the stateless HTTPS ingestion and worker services.
- Pub/Sub for durable asynchronous order events and a dead-letter topic.
- Cloud SQL for PostgreSQL for transactional order state.
- Secret Manager for database credentials and application secrets.
- Artifact Registry as the container image source.
- Cloud Logging, Cloud Monitoring, and Cloud Trace for observability.
- IAM and a dedicated service account for least-privilege workload identity.
- Serverless VPC Access and a VPC network for controlled access to the database.
The Terraform is intentionally limited to foundational infrastructure and a placeholder Cloud Run revision whose image is supplied by `var.container_image`. It does not build an image, configure application code, or apply resources. The project must already exist, and APIs are enabled by Terraform. Production should add customer-managed encryption keys, private egress controls, organization policies, and an explicit disaster-recovery strategy after the open questions are answered.
## Mermaid diagram
```mermaid
flowchart LR
Client[Authenticated client] --> Run[Cloud Run: order-api]
Run --> Pub[Pub/Sub: orders]
Pub --> Worker[Cloud Run: order-worker]
Pub --> DLQ[Pub/Sub: orders-dead-letter]
Run --> SQL[(Cloud SQL PostgreSQL)]
Worker --> SQL
Run -. secrets .-> SM[Secret Manager]
Worker -. secrets .-> SM
Run -. egress .-> VPC[Serverless VPC Access / VPC]
Worker -. egress .-> VPC
Run --> Obs[Logging / Monitoring / Trace]
Worker --> Obs
CI[CI: fmt, validate, plan] --> TF[Terraform]
TF --> Run
```
## Architecture description
Clients call the authenticated `order-api` service. The API validates the request, writes an idempotency/order record to PostgreSQL, publishes an order event, and acknowledges the request. The worker consumes events independently, updates transactional state, and allows failed messages to be retained in the dead-letter topic for replay. Both services use separate runtime identities in production; the reference Terraform uses one explicitly scoped identity to keep the sample small and documents the split as a hardening action.
Cloud Run provides stateless horizontal scaling. Pub/Sub absorbs bursts and decouples downstream work. Cloud SQL supplies relational transactions; its private IP and VPC path are intended for production hardening. Secret Manager avoids embedding credentials. Managed logging, monitoring, and tracing provide operational evidence.
The initial topology is single-region. Multi-region failover, custom domain/edge policy, backup configuration, and application-level authentication integration remain deployment decisions because the open questions are unresolved.
## Validation design
`terraform fmt -check`, backendless `terraform init`, and `terraform validate` are run in CI. `scripts/validate_artifacts.py` checks that the requirements, architecture, Mermaid diagram, Terraform, and guide contain the required sections and that no product names occur in the product-neutral requirements section. No apply is used. A credentialed `terraform plan` is optional and must use a disposable plan file.