Control Plane vs Data Plane
The separation between the system that manages configuration and the system that serves requests, which have very different reliability requirements.
The data plane moves the actual traffic: forwarding packets, serving queries, running requests. It is simple, high volume and must be extremely reliable. The control plane decides what the data plane should do: provisioning, scaling, registering endpoints, distributing configuration. It is complex, low volume, and correspondingly less reliable.
The pattern to internalise is that control planes fail more often than data planes, in every system, including every cloud provider's. Study any major cloud outage and the failure is usually in a control plane — a configuration propagation, a scaling subsystem, a registry — while the underlying data planes kept running for whatever was already provisioned.
The design consequences are direct. Do not put a control plane in a request path. Do not depend on being able to provision, scale or reconfigure during an incident, because that is exactly when the control plane is likely to be unavailable or throttled. And design failover to use capacity that is already running.
The related discipline is honest dependency accounting: a service that resolves a configuration value or fetches a secret per request has made a control plane a hard dependency of its data plane, and its real availability is now the product of both.