Control Plane and Data Plane
The separation between the machinery that makes changes to a system and the machinery that serves its traffic.
The data plane handles the actual work: routing packets, serving requests, reading and writing records. It runs constantly, is latency-sensitive, and should be simple.
The control plane makes changes: creating resources, updating configuration, scaling, promoting a replica. It runs occasionally, tolerates higher latency, and is inherently more complex because it coordinates.
Two design rules follow, and both are violated regularly:
They should fail independently. A control-plane outage should mean "no changes can be made", not "nothing works". Cloud providers architect for this deliberately, and it is why an EC2 API outage does not stop running instances.
The data plane should not depend on the control plane per request. A design that calls a configuration service, a registry or a policy API on every request has made a rarely-exercised, complex component a hard dependency of a hot path.
The recovery implication is the sharp one: if your recovery procedure requires the control plane, you cannot recover from a control-plane failure.