As enterprise data ecosystems grow in complexity, the need for strict security boundaries and operational isolation becomes increasingly important. Syntasa addresses these requirements through the architectural separation of the Control Plane and the Data Plane.
This separation allows the platform’s management services to reside in one environment (GCP Project) while the actual data processing and storage occur in another. This model, commonly referred to as “Cross-Project Support,” provides a foundation for secure, scalable, and compliant data engineering.
The “Brain” vs. The “Muscle”
To better understand this architecture, it is useful to think of the platform as two distinct functional layers.
The Control Plane — “The Brain”
The Control Plane acts as the administrative hub of the Syntasa platform. It is responsible for orchestration, identity management, and the user interface. Rather than storing or processing raw data, the Control Plane issues instructions to the Data Plane.
Typical Location
A centralized GCP project managed by platform administrators.
Key Components
| Component | Description |
|---|---|
| Syntasa UI | Web interface used to build pipelines and notebooks. |
| Job Orchestrator | Service responsible for scheduling and triggering workflows. |
| Metadata Store | Stores workflow definitions, user roles, and job history. |
| Auth Service | Manages platform access and identity resolution. |
The Data Plane — “The Muscle”
The Data Plane is the execution environment where data storage and processing take place. This is where compute resources are provisioned and workloads are executed.
Typical Location
A customer-owned or team-specific GCP project.
Key Components
| Component | Description |
|---|---|
| Compute (Dataproc) | Clusters and Spark jobs responsible for executing workloads. |
| Storage (GCS) | Buckets used for staging, temporary files, and final outputs. |
| EventStore (BigQuery / Pub/Sub) | Services used for ingestion, event processing, and querying. |
| Connections | Integrations with external data sources and destinations. |
Why Separate the Planes?
Security and Least Privilege
Separating the Control Plane and Data Plane establishes a strong security boundary. The Control Plane only requires the minimum IAM permissions necessary to trigger jobs in the Data Plane.
Because raw data remains entirely within the Data Plane project, platform administrators operating in the Control Plane cannot inadvertently access sensitive datasets or storage objects.
Billing and Cost Attribution
This architecture simplifies financial management by ensuring all compute and storage costs are billed directly to the Data Plane project.
As a result, organizations can more easily attribute cloud spending to specific business units, departments, or teams.
Compliance and Governance
Many regulatory and compliance frameworks require separation between application management layers and data processing environments.
With this architecture, organizations can apply distinct:
- Security policies
- Audit logging configurations
- Encryption strategies and keys
within the Data Plane without impacting platform availability or operational management.
How the Planes Communicate
Syntasa securely bridges communication between projects using an API-driven model.
IAM Trust
The Syntasa Service Account located in the Control Plane is granted scoped IAM roles within the Data Plane project, such as:
dataproc.editorstorage.admin
This enables the platform to manage workloads securely without excessive permissions.
Cross-Project API Calls
When a workflow is triggered, the Job Orchestrator sends authenticated API requests to GCP services such as Dataproc while targeting the Data Plane Project ID.
Networking (Kafka NLB)
To monitor workload execution and job progress, Syntasa uses a regional TCP Load Balancer.
This provides a stable external IP address that allows compute nodes in the Data Plane to communicate status updates back to the Control Plane Kafka brokers, even when operating across separate VPC networks.
Flexible Routing: The Two-Tier Model
Syntasa provides two levels of configuration for managing Control Plane and Data Plane separation.
Platform Default
A global setting within the Infrastructure UI routes all platform operations to a primary Data Plane project by default.
Runtime Override
Individual Runtime configurations can optionally override the default Data Plane.
This enables a single Syntasa installation to manage multiple Data Plane environments simultaneously. For example:
- Team A may use a Runtime configured for “Project A”
- Team B may use a Runtime configured for “Project B”
Summary
The separation of the Control Plane and Data Plane is a foundational capability for enterprise-grade deployments.
This architecture enables Syntasa to scale alongside organizational security, governance, and compliance requirements while supporting robust multi-tenant data operations.
Most importantly, it ensures that your data remains exactly where it belongs — fully isolated and under your organization’s control.