PATTERN Cited by 1 source
Control plane self-hosting¶
Pattern¶
Build a service's control plane on top of the service itself — so the team operating the service experiences every rough edge before customers do. The bookkeeping database that manages customer resources is itself an instance of the managed resource.
Motivation¶
- Dogfooding at the infra layer. The team feels scaling limits, latency spikes, and failure modes in their own operational loop, creating strong incentive to fix them.
- Auto-scaling bookkeeping. As customer adoption grows, the control-plane workload grows. If the control-plane DB is the product itself, it scales automatically with adoption.
- Availability inheritance. If the product is designed for AZ-failure survival, the control plane inherits that property for free.
The circular-dependency problem¶
A control plane cannot depend on the thing it controls for its initial bootstrap. Breaking this circularity requires a separate bootstrapping path (manual provisioning, a seed cluster, or a different backing store for the earliest phase).
Seen in¶
- Aurora DSQL — "When it came time to choose a database for the DSQL control plane, we chose DSQL." Benefits: (a) bookkeeping DB auto-scales with DSQL adoption; (b) AZ outages don't kill the control plane because DSQL survives single-zone failures. (Source: sources/2026-08-04-allthingsdistributed-on-building-scalable-control-planes)
- Spanner — Google's Spanner control plane runs on Spanner.
- CockroachDB — internal metadata stored in regular ranges.
Trade-offs¶
- The team must be confident the product is mature enough to host its own operational data.
- Debugging is harder: a bug in the product can cascade into the control plane, making the system unable to heal itself.
- Initial deployment requires a cold-start strategy.