⌘ The Architecture Reference

Cld saas · Cloud & SaaS · Intermediate

Control Plane vs. Application Plane

Every SaaS environment divides into a control plane that orchestrates all tenants and an application plane where the multi-tenant product features live.

Cld saas Intermediate ⏱ 5 min read Complete

🧭 Analogy

An apartment complex has a management office and the apartments themselves. The office (control plane) handles leases, keys, billing, and the master dashboard for every unit — but nobody lives there. The apartments (application plane) are where tenants actually live, each isolated behind its own locked door. Both are essential, and they run on different schedules.

The two halves of every SaaS architecture

Golding’s most reusable mental model is that every SaaS environment divides into a control plane and an application plane. They have separate versioning, update, and deployment lifecycles, and an environment qualifies as multi-tenant as long as a control plane manages tenant environments through a unified experience — even if the application plane is fully dedicated or fully shared.

graph TD
subgraph CP["Control plane (spans ALL tenants — not multi-tenant itself)"]
  ON["Onboarding<br/>(the front door)"]
  ID["Identity<br/>(binds user to tenant)"]
  ME["Metrics"]
  BI["Billing"]
  TM["Tenant Management<br/>(source of truth)"]
  AC["System admin console"]
end
subgraph AP["Application plane (the product + multi-tenant principles)"]
  TC["Tenant context (JWT 'passport')"]
  ISO["Tenant isolation"]
  DP["Data partitioning"]
  RT["Tenant routing"]
  DEP["Tenant-aware deployment"]
end
CP -- unified experience --> AP

Inside the control plane

The control plane is the “single pane of glass” that orchestrates and operates the SaaS solution, hosting cross-cutting foundational services and an admin application. Its common services are:

  • Onboarding — orchestrates introducing a new tenant and assigning a unique identifier (“the front door”).
  • Identity — binds each user to a tenant, producing the SaaS identity.
  • Metrics — centralized capture and aggregation of tenant activity, with the tenant at the center.
  • Billing — integrates with homegrown or commercial billing, connected to onboarding and metering.
  • Tenant Management — the single source of truth for tenant state (identifier, plans, policies, identity config, active/inactive status).

The control plane is not multi-tenant

A common surprise: the control plane’s services are not themselves multi-tenant — they span all tenants. Multi-tenancy lives in the application plane. Confusing the two leads teams to over-engineer tenant isolation into services that legitimately need a cross-tenant view.

Inside the application plane

The application plane is where the SaaS product’s features and multi-tenant principles live — a “blank canvas” with no single blueprint, shaped by business, domain, and legacy considerations. Its cross-cutting constructs:

  • Tenant context — commonly packaged as a JWT, the “passport” that flows into routing, logging, metrics, and data access.
  • Tenant isolation — a key argument: deploying a resource in a dedicated/siloed model does not equal isolation. Dedicated deployment only makes isolation easier; every plane must add explicit constructs to enforce it (see tenant isolation models).
  • Data partitioning — dedicated vs. shared storage, often a per-service decision.
  • Tenant routing — multi-tenant-aware routing using tenant context at multiple levels.
  • Multi-tenant application deployment — DevOps must be tenant-aware, since a service may be deployed many times.

The gray area and the forcing function

Some concepts sit between the planes: tiering (variations at different price points, reaching into routing, security, and throttling — Golding leans toward the control plane); the three user roles (tenant admin, ordinary tenant users, and system admin staff using a purpose-built console); and tenant provisioning (kept closest to the resources in the application plane, but as a standalone, encapsulated piece of onboarding).

graph TD
SA["System admin staff"] --> AC["System admin console<br/>(control plane)"]
TA["Tenant admin"] --> APP["SaaS product<br/>(application plane)"]
TU["Tenant users"] --> APP
AC -- operates across all tenants --> APP

Start with the control plane

SaaS foundations often start with the control plane because it acts as a forcing function — it injects tenancy from the outset and cascades into tenant-aware logs, metrics, partitioning, and isolation. But don’t treat the planes as absolutes: technology need not match across them (e.g., a serverless control plane with a container application plane), they can be loosely coupled or share an environment, and the split is a useful model, not a rigid prescription.

See also

When to use it — and when not

✅ Reach for it when

  • Structuring a new SaaS solution or migration around the control plane as a forcing function
  • Deciding where cross-cutting services (onboarding, identity, billing, metrics) belong
  • Separating versioning and deployment lifecycles of operations vs. product

⛔ Think twice when

  • Treating the two planes as rigid absolutes rather than a useful mental model
  • Assuming control-plane services must themselves be multi-tenant
  • Forcing the same technology stack across both planes
cld-saasSaaS Foundations

SaaS is a business model first — a unified, single-version service experience for tenants — and multi-tenancy means collective management, not necessarily shared infrastructure.

cld-saasTenant Onboarding and Identity

Start with onboarding and identity: a fully automated front door that binds every user to a tenant and carries tenant context downstream as a JWT.

cld-saasTenant Isolation Models

Silo, pool, and bridge express how resources map to tenants — but deployment is not isolation; true isolation needs a separate gatekeeper scoped by tenant context.

Check your understanding

Score: 0 / 4

1. What is the control plane?

The control plane hosts cross-cutting foundational services (onboarding, identity, billing, metrics, tenant management) and an admin app spanning all tenants.

2. Are the control plane's services themselves multi-tenant?

Control-plane services operate across all tenants; multi-tenant principles live in the application plane.

3. What lives in the application plane?

The application plane is a 'blank canvas' with no single blueprint — where multi-tenant principles and the product features live.

4. Why does Golding say SaaS foundations often start with the control plane?

Starting with the control plane forces tenancy into the design early instead of bolting it on later.

Comments

Sign in with GitHub to join the discussion.