# Google Cloud architecture

Google Cloud diagrams hang off the project boundary, and services within a project are usually reached through well-known managed endpoints rather than through network topology.

That makes text diagrams work particularly well here, because there is less positional meaning to preserve.

---

## When to reach for one

* Design documents, especially for serverless and data pipelines.
* Explaining a Pub/Sub topology and who subscribes to what.
* Cost and quota conversations, where the service list is the subject.

---

## How to draw it in Capable

| **Route**     | **Use when**                                             |
| ------------- | -------------------------------------------------------- |
| draw.io       | Official Google Cloud icon set.                          |
| Mermaid or D2 | Serverless and event-driven designs, which change often. |

---

## A worked example

A Cloud Run and Pub/Sub pipeline:

![Google Cloud architecture](https://help.gocapable.com/images/att1418461241.svg)

The source, which you can paste into a new diagram and edit:

```
flowchart LR
  U([Users]) --> LB[Cloud Load Balancing]
  LB --> RUN[Cloud Run: api]
  RUN --> SQL[(Cloud SQL)]
  RUN --> TOPIC{{Pub/Sub: events}}
  TOPIC --> WORKER[Cloud Run: worker]
  TOPIC --> BQ[(BigQuery)]
  WORKER --> GCS[(Cloud Storage)]
  WORKER --> SQL
```

---

## A few things that catch people out

* Draw the project boundary; IAM and quota both follow it.
* Pub/Sub topics deserve to be nodes. Hiding them loses the fan-out.
* Regional versus multi-regional is worth annotating if latency or cost is under discussion.

---

## Related

[Kubernetes diagramPods, services, ingress, namespaces.](https://help.gocapable.com/diagrams/kubernetes-diagram.html)

[CI/CD pipeline diagramCommit to production, with the gates visible.](https://help.gocapable.com/diagrams/ci-cd-pipeline-diagram.html)

[ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html)

---

_Draw the trust boundary._