GCP Architecture Guide

How to Create a GCP Data Platform Diagram

A well-designed architecture diagram is the difference between a data platform that scales smoothly and one that becomes a maintenance nightmare. This guide shows you how to design and document GCP data platforms that teams can actually understand and operate.

18 min readFor Data Engineers & ArchitectsGCP-specific examples

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

94/20003 credits left
Try:

No account needed · Editable canvas, not a picture

1. Why GCP Data Platform Diagrams Matter

Your GCP data platform is invisible. Services run in the cloud, data flows through APIs, and failures happen silently. A good architecture diagram is the map that makes the invisible visible—showing how data moves, where it's stored, and who can access it.

The Cost of Poor Documentation

Without clear diagrams, teams spend 40% of their time hunting through Cloud Console, checking IAM policies, and trying to figure out which Dataflow job writes to which BigQuery table. That's 16 hours per week of a senior engineer's time wasted on archeology.

A good GCP diagram delivers three outcomes:

Faster Debugging

When data is missing, the diagram shows exactly which Cloud Storage bucket, Dataflow job, and BigQuery table to check. No more guessing.

Onboarding

New engineers understand the entire platform in 30 minutes instead of 3 months. Show them the diagram, not Terraform configs.

Security Review

Auditors and security teams can see IAM boundaries, VPC Service Controls, and data access patterns at a glance.

From experience

I've joined teams where the only documentation was "check the console." It took weeks to understand what was running. The teams with clear diagrams? I was productive on day one. Documentation isn't overhead—it's velocity.

2. Core GCP Data Services

GCP has 100+ services, but modern data platforms are built on a core set of 8-12. Here's what each service does and when to use it in your diagram.

Cloud Storage

Storage

Object storage for your data lake. Stores raw, processed, and curated data at scale with multiple storage classes.

Use when: Storing any data at scale. Organize with prefixes: gs://bucket/raw/, gs://bucket/processed/, gs://bucket/curated/

BigQuery

Data Warehouse

Serverless, petabyte-scale data warehouse. Fast SQL queries, ML integration, and seamless scaling.

Use when: Active analytics workloads, BI dashboards, ML training data. Query data from Cloud Storage via external tables or load it for best performance.

Dataflow

Stream + Batch

Unified stream and batch processing using Apache Beam. Auto-scaling, serverless execution.

Use when: Complex transformations, streaming data, windowing operations. Write once in Beam, run as stream or batch.

Pub/Sub

Messaging

Messaging service for event-driven architectures. Decouples producers from consumers with guaranteed delivery.

Use when: Real-time data ingestion, event streaming, microservices communication. Pairs with Dataflow for stream processing.

Cloud Composer

Orchestration

Managed Apache Airflow for workflow orchestration. Schedule and monitor data pipelines with DAGs.

Use when: Complex pipelines with dependencies, scheduled batch jobs, coordinating multiple services.

Dataproc

Spark/Hadoop

Managed Spark and Hadoop clusters. Fast cluster provisioning, integrates with Cloud Storage.

Use when: Existing Spark jobs, complex ML workloads, or when Dataflow doesn't fit. Cheaper than Dataflow for long-running batch jobs.

ServiceCategoryPrimary Use CasePricing Model
Cloud StorageStorageData lake, archivesPer GB stored
BigQueryData WarehouseAnalytics, BI, MLPer TB scanned
DataflowProcessingETL, streamingPer vCPU-hour
Pub/SubMessagingEvent streamingPer GB
Cloud ComposerOrchestrationWorkflow mgmtPer environment
DataprocProcessingSpark/HadoopPer vCPU-hour

3. Common GCP Architecture Patterns

Most GCP data platforms follow one of these proven patterns. Choose based on your latency requirements, data volume, and team skills.

Pattern 1: BigQuery-Centric (Recommended for Most)

Simple, cost-effective, serverless analytics

Sources → Cloud Functions → Cloud Storage (staging) → BigQuery → Looker/Data Studio

Best for:

  • • Most analytics workloads
  • • Teams without Spark expertise
  • • Budget-conscious projects
  • • Fast time-to-value

Key services:

  • • Cloud Storage (raw data)
  • • BigQuery (warehouse)
  • • Cloud Functions (lightweight ETL)
  • • Cloud Scheduler (orchestration)

Pro: Minimal ops overhead. BigQuery handles scaling, optimization, and backups. Most cost-effective for <1TB daily data.

Pattern 2: Streaming with Dataflow

Real-time processing for event-driven systems

Sources → Pub/Sub → Dataflow → BigQuery + Cloud Storage → Consumers

Best for:

  • • Real-time dashboards
  • • Event-driven architectures
  • • IoT/sensor data
  • • Complex windowing logic

Key services:

  • • Pub/Sub (ingestion)
  • • Dataflow (transformation)
  • • BigQuery (serving)
  • • Cloud Monitoring (observability)

Pro: Sub-second latency. Unified code for batch and streaming. Auto-scales with traffic.

Pattern 3: Data Lake with Medallion Architecture

Multi-zone storage for large-scale batch processing

Sources → Cloud Storage Bronze → Dataproc → Silver → Gold → BigQuery

Best for:

  • • Large-scale batch processing
  • • Existing Spark pipelines
  • • Complex ML feature engineering
  • • Cost optimization at scale

Layers:

  • • Bronze: Raw, immutable data
  • • Silver: Cleaned, conformed
  • • Gold: Business-ready aggregates
  • • BigQuery: Query layer

Note: Requires more ops overhead. Use Dataflow if you don't have Spark expertise or need streaming.

Pattern 4: Modern Data Stack with dbt

ELT with transformation-in-warehouse

Sources → Fivetran/Airbyte → BigQuery (raw) → dbt (transformation) → BigQuery (marts)

Best for:

  • • SaaS data integration
  • • Analytics engineering teams
  • • SQL-first transformations
  • • Version-controlled data models

Key tools:

  • • Fivetran (EL connectors)
  • • dbt (transformation)
  • • BigQuery (compute + storage)
  • • Looker (BI)

Pro: Fast setup, great for analytics teams. No infrastructure to manage. Version control for transformations.

Choosing a Pattern

Start with Pattern 1 (BigQuery-Centric) unless you have specific requirements. It's the simplest, most cost-effective, and easiest to operate. Add complexity (Dataflow, Dataproc, dbt) only when you need streaming, Spark, or advanced transformation logic.

4. Step-by-Step Design Process

Here's how to design a GCP data platform diagram that actually helps your team operate the system.

1

Map Data Sources

Start by listing all data sources. Be specific: is it an API, database replication, file drop, or event stream?

Examples:

  • • PostgreSQL (Cloud SQL) - replicated via Datastream
  • • Salesforce API - polled every hour via Cloud Functions
  • • Web events - streamed via Pub/Sub
  • • CSV files - dropped in Cloud Storage bucket
2

Define Ingestion Layer

How does data get into GCP? Match ingestion method to source characteristics.

Decision tree:

  • Real-time events? → Pub/Sub
  • API polling? → Cloud Functions + Cloud Scheduler
  • Database replication? → Datastream
  • SaaS connectors? → Fivetran/Airbyte
3

Design Storage Layer

Organize Cloud Storage buckets by data maturity. Include bucket names in your diagram.

Bucket structure:

  • • gs://company-data-raw/ - immutable source data
  • • gs://company-data-staging/ - intermediate transformations
  • • gs://company-data-curated/ - analytics-ready
  • • gs://company-data-archive/ - cold storage
4

Model Transformation Layer

Show how data gets cleaned, joined, and aggregated. Include job names and schedules.

Options:

  • BigQuery scheduled queries - simple SQL transformations
  • Dataflow jobs - complex ETL, streaming
  • dbt models - version-controlled SQL
  • Dataproc jobs - Spark/PySpark transformations
5

Define Serving Layer

Where do consumers query data? Include dataset names and table patterns.

BigQuery datasets:

  • • project.raw_data - source system replicas
  • • project.staging - intermediate models
  • • project.analytics - BI-ready tables
  • • project.ml_features - ML training data
6

Add Orchestration & Monitoring

Show how pipelines are scheduled and monitored. Include alerting paths.

Key components:

  • • Cloud Composer DAGs for complex workflows
  • • Cloud Scheduler for simple cron jobs
  • • Cloud Monitoring for metrics & alerts
  • • Cloud Logging for pipeline debugging
7

Document Access Patterns

Show who consumes data and how. Include service accounts and IAM roles where relevant.

Consumer types:

  • • Looker/Data Studio dashboards
  • • ML models (Vertex AI)
  • • Reverse ETL to operational systems
  • • Data APIs for applications

5. Diagram Best Practices

A diagram is only useful if people actually use it. Follow these principles to create diagrams that stay relevant.

Use Real Resource Names

Don't write "BigQuery Dataset." Write "analytics_prod" so engineers can find it in the console.

✅ gs://company-data-raw/
❌ Cloud Storage Bucket

Show Data Flow Direction

Arrows matter. Use clear, unambiguous arrows to show which way data moves.

Source → Pub/Sub → Dataflow → BigQuery

Include Schedules

Annotate batch jobs with their schedule. "Daily at 2 AM" or "Every 15 min" tells you when to expect fresh data.

Dataflow job: sales_etl (runs hourly)

Layer by Abstraction

Group services by function: ingestion, storage, transformation, serving. Makes it scannable.

Use horizontal layers or color-coded zones

Highlight Critical Paths

Mark pipelines that feed executive dashboards. When these break, people notice immediately.

Use bold lines or ⚠️ icons for SLA-critical

Version Your Diagrams

Date your diagrams. "Updated Dec 2025" tells readers if it's current or stale.

Store in Git with the rest of your docs

Common Mistakes to Avoid

  • • Using generic labels ("Database," "API") instead of actual names
  • • Showing every table—focus on key data flows, not exhaustive catalogs
  • • Mixing logical and physical layers—pick one viewpoint
  • • Forgetting to update when you change infrastructure

From experience

The best diagrams are the ones that get referenced during incidents. If your team pulls up your diagram when debugging, you've succeeded. If they open the Cloud Console instead, your diagram needs more detail.

6. Tools for Creating GCP Diagrams

ToolBest ForGCP IconsCollaborationPricing
DatadefData-specific diagrams✅ Built-in✅ Real-timeFree tier
LucidchartGeneral architecture✅ Official library✅ Excellent$7.95/mo
Draw.ioSimple diagrams✅ Import library⚠️ BasicFree
MiroWorkshops, brainstorming⚠️ Manual✅ Great for teams$8/mo
Google SlidesQuick sketches❌ None✅ Built-in sharingFree

Official GCP Icons

Google provides official icon sets for architecture diagrams. Using consistent icons makes diagrams instantly recognizable.

Download GCP icons →

Diagram-as-Code

For teams that prefer code, tools like Diagrams (Python) let you generate architecture diagrams from code.

Explore Diagrams library →

7. GCP Diagram Design Checklist

Data sources are clearly labeled

Include system names, update frequency, and connection method (API, Pub/Sub, file drop).

Ingestion layer shows method

Pub/Sub for streaming, Cloud Functions for polling, Datastream for replication—be specific.

Storage layer uses real bucket names

gs://company-data-raw, not "Cloud Storage Bucket." Engineers need to find it.

Transformation jobs include schedules

Dataflow job runs hourly, dbt models refresh daily at 3 AM—show the cadence.

BigQuery datasets are named

project.raw_data, project.analytics—don&apos;t just say "BigQuery."

Data flow direction is unambiguous

Clear arrows showing source → transformation → destination.

IAM boundaries are visible

Show which service accounts access what, especially for security-sensitive data.

Monitoring and alerting included

Where do logs go? How do failures alert? Include Cloud Monitoring integration.

Critical paths are highlighted

Mark pipelines that feed executive dashboards or SLA-critical systems.

Diagram is dated and versioned

Last updated: Dec 2026. Stored in Git alongside infrastructure code.

Pro Tip

The "New Hire Test"

Show your diagram to a new engineer and ask: "Where would you look if data stopped flowing to this dashboard?" If they can answer in 30 seconds, your diagram is good. If they need to ask clarifying questions, add more detail.

8. Frequently Asked Questions

What are the core GCP services for a data platform?

The core services are: Cloud Storage (data lake storage), BigQuery (serverless data warehouse), Dataflow (stream and batch processing), Pub/Sub (messaging), Cloud Composer (workflow orchestration), Dataproc (managed Spark/Hadoop), and Data Catalog (metadata management).

What is the medallion architecture in GCP?

The medallion architecture organizes data into three layers in Cloud Storage: Bronze (raw ingested data), Silver (cleaned and conformed data), and Gold (aggregated business-level data). Data progresses through these layers using Dataflow or Dataproc, with final analytics in BigQuery.

Should I store data in Cloud Storage or BigQuery?

Use Cloud Storage for raw data, archives, and data lake storage (cost-effective for long-term storage). Use BigQuery for active analytics data that needs fast SQL queries. The typical pattern is: ingest to Cloud Storage → transform → load to BigQuery for BI and ML.

How do I document data flow in GCP?

Document data flow by showing: source systems → ingestion layer (Pub/Sub/Cloud Functions/Dataflow) → storage (Cloud Storage buckets by zone) → transformation (Dataflow/Dataproc) → serving layer (BigQuery) → consumers (Looker/Data Studio/ML). Include bucket names, dataset IDs, and pipeline details.

Should I use Dataflow or Dataproc?

Use Dataflow for streaming, unified batch/stream processing, and if you don't have Spark expertise (Apache Beam is simpler). Use Dataproc for existing Spark jobs, complex ML workflows, or when you need full control over cluster configuration. Dataflow is easier to operate but can be more expensive for large batch jobs.

How often should I update my GCP architecture diagram?

Update your diagram whenever you add/remove services, change data flows, or modify critical pipelines. Treat it like code documentation—if the infrastructure changes, the diagram should change with it. Schedule a quarterly review to catch drift. Store diagrams in Git alongside Terraform/infrastructure code.

Build Your GCP Data Platform Diagram

Create clear, accurate diagrams of your GCP data platform with BigQuery, Cloud Storage, Dataflow, and all your key services. Generate diagrams in minutes, not hours.