GCP platform engineering case study
SignalDesk Cloud Launch
A deployable field-service booking application used to prove how a small business can combine product delivery, private data, keyless CI/CD, policy as code, observability, and cost controls.
Business problem
Small teams need a reliable system without inheriting enterprise platform overhead.
A service business needs customers to reserve live availability, operations to manage the same records, and engineers to release changes without exposing a database or sharing permanent cloud credentials. SignalDesk turns that practical requirement into a complete, reviewable platform.
The application uses synthetic data and a public demonstration operations board. Staff identity and role-based authorization are explicit milestones before real customer use.
Architecture 01 · runtime
The request path is public only at Cloud Run.
Next.js and FastAPI ship as one non-root container. FastAPI reaches a private-only PostgreSQL instance through Direct VPC egress and Private Service Access. IAM, network transport, and database login are intentionally shown as different controls.
Private path
Cloud SQL has no public IPv4 address. Serverless traffic leaves Cloud Run only for private ranges.
Layered authentication
IAM authorizes the workload; PostgreSQL validates the database user and injected password.
Traceable requests
A request ID connects browser responses to structured Cloud Logging records.
Architecture 02 · delivery
GitHub proves the change before Google Cloud accepts an identity.
Pull requests are read-only. Protected main delivery repeats the gates, selects infrastructure, application, or both, and exchanges trusted OIDC claims for short-lived credentials. Terraform applies the exact policy-checked plan; application releases are promoted only after a zero-traffic candidate passes smoke tests.
Application proof
Follow one booking from customer request to completed service.
This sequence exercises the frontend, FastAPI validation, database persistence, conflict-aware availability, operations retrieval, and the booking state machine.
A real service, not a static mock-up
What it proves: The public Cloud Run URL serves the deployed booking workspace and reports the platform as operational.
Why it matters: A client can test the same system the engineering team operates.
Customer request capture
What it proves: The Next.js interface loads a real service catalog and sends validated requests to FastAPI.
Why it matters: A simple flow replaces phone-and-spreadsheet coordination.
API-backed availability
What it proves: Arrival windows respond to the selected service, date, and bookings already stored in PostgreSQL.
Why it matters: The business avoids offering a slot that is no longer available.
Persisted confirmation with traceability
What it proves: FastAPI returns a booking reference and request ID after Cloud SQL commits the booking.
Why it matters: Customers receive a clear outcome and support can trace the exact request.
Operations retrieves the same record
What it proves: A later API request finds the booking in the operations view, demonstrating persistence beyond browser state.
Why it matters: The customer and field team work from one source of truth.
Controlled business-state transition
What it proves: The operations flow moves a confirmed appointment into its completed terminal state.
Why it matters: The workflow stays accountable from request to delivered work.
Runtime and private data path
Proving identity, secrets, and network isolation
These console views validate the deployed controls behind the runtime diagram. IAM authorization, the private network route, and PostgreSQL authentication are separate layers.
Managed runtime and bounded scaling
What it proves: Cloud Run reports a healthy service in us-east1, request metrics, latency percentiles, scale-to-zero, and a three-instance ceiling.
Why it matters: The service can absorb demand without creating an unbounded database or cost event.
Immutable revision receiving production traffic
What it proves: The verified revision receives 100% of traffic and records the dedicated GitHub deploy identity.
Why it matters: Every release is identifiable and can be rolled back to a previous revision.
Dedicated runtime service account
What it proves: The revision runs as signaldesk-dev-runtime rather than a broad default identity.
Why it matters: Least privilege limits what an application compromise could reach.
Secret reference, not plaintext configuration
What it proves: DB_PASSWORD points to a Secret Manager version while the database name, user, and connection name remain normal configuration.
Why it matters: The credential never needs to be committed to GitHub or copied into a workflow variable.
Private PostgreSQL connectivity
What it proves: Cloud SQL uses Private Service Access, an internal address, SSL-only connections, and no public IPv4 endpoint.
Why it matters: The database is not directly exposed to the public internet.
Keyless delivery and DevSecOps
Proving who can deploy—and what must pass first
GitHub receives no permanent Google service-account key. OIDC claims are mapped and restricted before Google issues short-lived credentials to separate infrastructure and application identities.
Separate application and infrastructure trust
What it proves: Two active Workload Identity pools isolate the application-delivery and infrastructure-delivery boundaries.
Why it matters: A pipeline receives only the permissions required for its delivery lane.
Application OIDC claim restrictions
What it proves: Repository, owner, workflow, branch, and GitHub environment claims are mapped into an enforceable trust condition.
Why it matters: A token from an untrusted fork or workflow cannot silently become the deploy identity.
Infrastructure OIDC claim restrictions
What it proves: The infrastructure provider independently restricts the trusted main workflow and plan/apply environments.
Why it matters: Application delivery cannot inherit Terraform-level privileges.
Required pull-request evidence
What it proves: Application tests, dependency audits, Terraform validation, Checkov, OPA, Trivy, image scanning, and SBOM generation passed before merge.
Why it matters: Unsafe changes are rejected before they receive a cloud identity.
Path-aware main delivery
What it proves: The orchestrator repeats gates on the trusted commit and selects only the delivery lanes affected by the change.
Why it matters: The pipeline stays fast without weakening the checks that protect production.
Build once, verify, then promote
What it proves: The workflow scans one candidate, generates its SBOM, publishes by digest, deploys at 0% traffic, smoke-tests it, and only then promotes it.
Why it matters: A failed candidate leaves the serving revision untouched.
Infrastructure-only execution path
What it proves: Terraform plan and apply ran while application deployment was deliberately skipped.
Why it matters: Infrastructure and application releases do not overwrite each other’s ownership.
Policy-checked Terraform proposal
What it proves: The real binary plan becomes OPA input, receives a SHA-256 checksum, and is stored as protected evidence.
Why it matters: Review and policy decisions apply to the actual proposed change—not a recreated approximation.
Exact approved plan applied
What it proves: The apply job downloads the approved plan, verifies its checksum, and applies that same binary artifact after environment approval.
Why it matters: The reviewed infrastructure change cannot drift between approval and execution.
Operations and FinOps
Proving the system is observable and cost-aware
The application emits structured metadata rather than customer payloads. A browser-visible request ID connects a user action to the exact Cloud Run record.
Request-level log correlation
What it proves: Logs Explorer finds one request_completed event using the exact request ID returned to the browser.
Why it matters: Support can move from a customer report to a specific backend request quickly.
Structured operational metadata
What it proves: The log records method, path, status, duration, timestamp, and request ID without logging the booking payload.
Why it matters: The team gets useful diagnostics while reducing sensitive-data exposure.
Monthly budget guardrail
What it proves: The development project has a USD 10 monthly budget with 50%, 90%, and 100% alert thresholds.
Why it matters: Unexpected spend becomes visible early; the design states honestly that an alert is not a hard spending cap.
Engineering judgment
The trade-offs are part of the design.
One Cloud Run service
Why: Next.js is exported into the FastAPI container, producing one origin, one artifact, and one scaling boundary.
Trade-off: Frontend and API cannot scale or release independently. That is acceptable for this lean first release, but a larger team may split them.
Cloud Run instead of Kubernetes
Why: The client problem needs a managed container runtime, not cluster and node operations.
Trade-off: Less platform flexibility in exchange for a smaller operational and cost burden.
Private Cloud SQL with password authentication
Why: It keeps the database off the public internet and makes the first version practical to operate.
Trade-off: The password must be rotated and protected. IAM database authentication is the next security upgrade.
Single region and zonal database
Why: It keeps a portfolio-grade development environment within a USD 10 alerting target.
Trade-off: This is not regional disaster recovery. Production requires an RTO/RPO decision, HA, and tested recovery.
Technology map