Venue Setup Tasks and Completion Checks for an Event Company
Supports a fictional event company's venue setup: site leaders register and assign tasks, and setup staff record completion on smartphones. The screens and API run on Cloud Run, and the API reaches Memorystore for Redis and Cloud SQL over private IPs through a Serverless VPC Access connector. The screens and API are public without authentication, and Redis transit encryption is disabled. The business scenario is a fictional example prepared by IceShore, not a real company or system. Source: https://github.com/GoogleCloudPlatform/terraform-google-three-tier-web-app/tree/69885ccd8aaa9b2e9ab2307fbe6b7242aa1a2b17 (Copyright 2021 Google LLC; License: Apache License 2.0). The original files are reproduced without modification. The full license text is in the bundled THIRD_PARTY_NOTICES.yaml.
Actors
Use cases
- Setup staff open the task screen
- Setup staff check tasks and record completion
- Site leaders register and assign tasks
This diagram supports a fictional event company's venue setup: site leaders register and assign setup tasks, and setup staff record completion on their smartphones. The task screen and the task API run on Cloud Run on Google Cloud. The API connects through a Serverless VPC Access connector to a private-IP Memorystore for Redis read cache and a Cloud SQL database (PostgreSQL 14 by default). The business scenario is a fictional example prepared by IceShore; the source is a Terraform-based Todo app from GoogleCloudPlatform/terraform-google-three-tier-web-app (Apache-2.0).
Resources and data flow behind the task screen and task records
The browser on a setup staff member's smartphone first loads static HTML/JS/CSS from the Cloud Run frontend service (fe, container port 80). Browser-side JavaScript then calls the Cloud Run API service (api) directly. The api URL is passed to fe in the ENDPOINT environment variable. In this scenario, each todo item in the original template is treated as one setup task.
With vpc-access-egress=all, the API routes all egress through the Serverless VPC Access connector (10.8.0.0/28) into the private network. Behind it are: - Memorystore for Redis: Basic tier, 1 GB, Redis 6.x, port 6379. - Cloud SQL: PostgreSQL 14 by default, port 5432, private IP only.
Both Cloud Run services grant roles/run.invoker to allUsers, so anyone can call them without authentication. Redis transit_encryption_mode is set to DISABLED.
Use cases for setup staff and site leaders
The diagram has three use cases.
"Setup staff open the task screen": on the morning of the event, setup staff access the fe service over HTTPS from their smartphone browsers. fe only serves static HTML/JS/CSS and stores no data.
"Setup staff check tasks and record completion": browser JavaScript calls the api service over HTTPS to list the staff member's tasks and mark finished ones as complete. Reads check Redis first; cache misses and all writes go to the todo database on Cloud SQL.
"Site leaders register and assign tasks" uses the same api. Site leaders register tasks and assign them to staff by the day before, and on the day they reassign delayed tasks to other staff.
Figures such as 150 staff, 10 site leaders and 100-300 tasks per event are assumed values for this fictional scenario; they are not in the IaC.
Source IaC (files and main resource types)
Source: https://github.com/GoogleCloudPlatform/terraform-google-three-tier-web-app (commit 69885ccd8aaa9b2e9ab2307fbe6b7242aa1a2b17, Apache-2.0 license). Target files: main.tf and variables.tf.
Main resource types in main.tf: - google_cloud_run_service (api and fe) - google_cloud_run_service_iam_member (public, unauthenticated access) - google_vpc_access_connector - google_redis_instance - google_sql_database_instance, google_sql_database and google_sql_user - google_compute_network, google_compute_global_address and google_service_networking_connection (VPC peering for private Cloud SQL access) - google_service_account and google_project_iam_member - time_sleep and random_id main.tf also uses the project_services module to enable APIs.
Variables in variables.tf: - project_id - region (default us-central1) - zone (default us-central1-a) - deployment_name (default three-tier-app) - database_type (mysql or postgresql, default postgresql) - labels - enable_apis - run_roles_list (default roles/cloudsql.instanceUser and roles/cloudsql.client)
How this diagram was made, and the business scenario
This diagram is based on the IaC in the public repository (main.tf and variables.tf). An AI wrote the diagram description (ADL) through IceShore's MCP (Model Context Protocol) server, and IceShore rendered it. The ADL ties each use case's entry point, traffic paths and storage to resources in main.tf: api, fe, google_vpc_access_connector.main, google_redis_instance.main and google_sql_database_instance.main.
The original template is a general three-tier web app in which users view, create, update and delete todos. The event company's venue setup scenario, the setup staff and site leaders, and the counts are not in the IaC, so they were added in the ADL as a fictional example prepared by IceShore. It is not a real company or system.
FAQ
How does the Cloud Run API reach Redis and Cloud SQL?
The api service has the vpc-access-connector and vpc-access-egress=all annotations, so it reaches the private network through the Serverless VPC Access connector. - Redis is attached to that network with connect_mode=DIRECT_PEERING. - Cloud SQL has ipv4_enabled=false and only a private IP, reached via Service Networking VPC peering (a /16 internal address range).
What changes if database_type is set to mysql?
In the IaC, setting database_type to mysql changes the following: - The database version becomes MYSQL_8_0. - The API image becomes todo-api. - The DB user becomes the password-based user foo. - The API gets the MySQL set of environment variables. The cloudsql.iam_authentication flag and the IAM service-account DB user, which are set only for PostgreSQL, are not used. This diagram shows the default PostgreSQL case (port 5432).
How does the task screen know where the API is?
The fe container receives the api service URL (google_cloud_run_service.api.status[0].url) in the ENDPOINT environment variable. Browser-side JavaScript then calls the API at that URL directly.
Source: GoogleCloudPlatform/terraform-google-three-tier-web-app（Apache-2.0）
Load your IaC to get a diagram like this for your own system. What is IceShore
