Data Plane vs Control Plane

The Division of Labor

 DATA PLANE — the fast path:
   proxies (envoy-class) intercepting every request.
   per-connection work: TLS, routing decision, retries,
   metrics emission. microsecond-class decisions.
   STATELESS-ish: acts on config it was GIVEN.

 CONTROL PLANE — the slow brain:
   watches services/endpoints/policies; computes config;
   PUSHES it to every proxy (xDS protocols).
   second-to-second class reactions. THE source of truth.

 [control plane] ──config/policy/certs──► ┌──────────┐
        ▲                                 │ data plane│
   k8s API, registries,                   │ proxy×N   │
   policy repos                           └──────────┘

Why the Split Matters

 the separation delivers each plane's properties:

 DATA plane design goals:
 □ BORING and fast: no external dependencies on hot path
   (control plane DOWN? traffic keeps flowing on last config!)
 □ uniform behavior across fleet via identical binaries

 CONTROL plane design goals:
 □ authoritative + consistent: one truth of desired state
 □ incremental pushes: endpoint changes propagate in seconds,
   not full reconfigs
 □ integration hub: k8s services, DNS, cert rotation

 the availability story falls out:
 control-plane outage ≠ outage. data planes freeze on
 last-known-good. upgrades/changes pause; requests don't.
 (verify YOUR mesh's failure modes though — some features
 degrade harder than others.)

The xDS Flow

 how config actually reaches a proxy:

 1. proxy connects to control plane (gRPC stream)
 2. subscribes: LDS (listeners), RDS (routes),
    CDS (clusters), EDS (endpoints), SDS (secrets)
 3. control plane streams updates incrementally
 4. proxy applies atomically; ACKs/NACKs back

 practical consequence: endpoint change → all proxies
 updated within ~seconds WITHOUT restarts. this is why
 meshes make dynamic fleets tractable.

Question	Plane
”route 5% to v2”	control (policy)
“this specific request → v2”	data (execution)
“rotate certs monthly”	control
”present cert on this handshake”	data
”new pod appeared”	control notices → informs

Interview Framing

“Explain mesh architecture” scored shape: two-plane diagram with responsibilities split correctly, xDS push-model named, control-plane-outage property stated (traffic survives!), and the table-style question mapping applied live. Confusing which plane decides vs executes is the classic tell of someone who read marketing, not architecture.