Phase 6 — Interview Readiness Playbook

A senior Cloud Gateway loop at a place like Netflix typically has five kinds of conversations. This is how to be ready for each, with the labs that back each one up.

1. A coding screen — usually a data-structure/algorithm problem, but sometimes "parse this protocol" or "implement a rate limiter."
2. A systems-design round — "design an API gateway / a push-message system / a global load balancer." This is where you win or lose.
3. A deep-dive / "tell me about a hard thing you built" — they probe one project to the bottom. Have one story that goes 6 layers deep.
4. An operations / debugging round — "latency p99 just doubled, walk me through it." Data-driven root-cause, as the JD demands.
5. Behavioral / culture — ownership, conflict, mentorship, Netflix culture-deck alignment.

1. The systems-design playbook for gateway problems

Gateway design questions reward a specific structure. Use this skeleton; it signals you've actually operated one of these.

Step 0 — Separate data plane from control plane out loud

The single highest-signal move. Say it in the first 60 seconds:

"I'll split this into a data plane — the proxies on the request path, optimized for p99 latency and connection efficiency — and a control plane — the source of truth that computes config and pushes it to the fleet, optimized for correctness and safe propagation. They have completely different SLOs and failure modes."

Then draw the box diagram:

            control plane (correctness-optimized)
        ┌──────────────────────────────────────────┐
        │  config store → reconciler → xDS server   │
        └───────────────┬──────────────────────────┘
                        │ push config (LDS/RDS/CDS/EDS)
        ┌───────────────▼──────────────────────────┐
   ───▶ │  data plane: L4/L7 proxies (p99-optimized) │ ───▶ origins
 client └────────────────────────────────────────────┘

Step 1 — Pin the numbers

Always quantify. For a Netflix-scale edge: O(1M+) rps, hundreds of millions of devices, persistent connections for push. Derive: connections per node, memory per connection, config fan-out size, config change rate. "If a proxy holds 200k WebSocket connections at ~10KB state each that's ~2GB of connection state alone" tells the interviewer you think in budgets. (gw-05 has the real Pushy numbers.)

Step 2 — Walk the request lifecycle

For an L7 gateway, narrate the path and name where each concern lives:

accept (L4)
  → TLS terminate / mTLS verify        (gw-07)
  → decode HTTP/2 frames, demux streams (gw-02)
  → inbound filters: authn, routing, rate limit, header manip (gw-03)
  → pick origin: LB + subsetting from a pooled connection         (gw-04, gw-06)
  → proxy request body with backpressure                          (gw-01)
  → outbound filters: retries, circuit breaking, response rewrite (gw-06)
  → emit access log + trace span + metrics                        (gw-11)

Step 3 — Name the failure modes before they ask

This is the senior signal. Volunteer:

• Retry storms / metastable failure. A blip makes everyone retry, the retries are the new load, the system can't recover even after the original cause clears. Mitigation: retry budgets (cap retries to a % of original traffic), circuit breakers, load shedding, adaptive concurrency. (gw-06)
• Connection churn. Closing origin connections after each request burns CPU on TLS handshakes and floods the origin's accept queue. Mitigation: keep-alive pools per event loop + subsetting so a large fleet doesn't fan out to every origin. (gw-04)
• Thundering herd on config push. A control-plane change that invalidates every connection at once. Mitigation: jittered, incremental rollout; delta xDS; warm the new config before cutover. (gw-08)
• Head-of-line blocking. At L4 (one slow connection), at L7 (HTTP/1.1 pipelining), and even in HTTP/2 (TCP-level HOL — the reason for HTTP/3). (gw-02)
• Graceful drain of stateful nodes. You can't just SIGKILL a node holding 200k WebSockets. You need connection draining and client reconnect with backoff + jitter. (gw-05, gw-01)

Step 4 — Close with observability and rollout

"I'd ship this behind a flag, mirror production traffic to it (shadow), compare RED metrics and a golden-signal diff, then ramp with a sticky canary." That sentence alone reflects gw-11 and gw-12.

The five canonical questions, pre-solved

2. The deep-dive round

Have one project you can take six layers deep. Structure it as: problem → constraints → options-you-rejected → design → the bug you didn't expect → what you measured → what you'd do differently. The "options you rejected" and "the bug you didn't expect" are what separate a 5 from a 4. Each lab's docs/analysis.md is written as a model of this: it always has a "Tradeoffs worth flagging" and a "what production needs beyond this lab" section. Steal that structure for your own story.

3. The operations / debugging round

The JD: "identify root causes using data." Practice this script on a prompt like "p99 latency doubled at 14:03, go":

1. Scope it. One region or global? One route or all? One origin or all? (Narrow the blast radius before theorizing.)
2. Golden signals. Rate, Errors, Duration, Saturation. Which moved first? (gw-11)
3. Correlate, don't guess. Did a deploy, a config push, or an origin event line up with 14:03? Overlay the timelines.
4. Walk the path. Is the latency in TLS, in the filter chain, in the LB pick (a hot/ejected origin?), in the origin itself, or in connection acquisition (pool exhaustion → new connects → churn)?
5. Form a falsifiable hypothesis, then find the one metric that confirms or kills it. ("If it's pool exhaustion, pool.pending and connections.created.rate should be up. They are → it's churn.")
6. Mitigate, then fix. Shed load / shift traffic / roll back now; root-cause and durable fix after.

Memorize a short list of "what each symptom usually means":

4. Behavioral / Netflix-culture mapping

Prepare 3–4 stories and tag each with the dimensions below. Netflix specifically interviews for these.

5. The 30-60-90 day plan (say this if asked "what would your first quarter look like?")

• Days 0–30 — Learn the system, earn trust. Read the data-plane and control-plane code paths end to end. Trace one real request through every hop. Ship something small and safe (a metric, a filter, a runbook fix) to learn the deploy pipeline. Pair on an on-call shadow. Map the stakeholders.
• Days 30–60 — Own a slice. Take a real problem in your domain (e.g., a connection-efficiency or observability gap). Write the design doc. Run it through a design review as the author. Start the build behind a flag.
• Days 60–90 — Ship and measure. Shadow → canary → ramp the change. Show a before/after metric. Write the postmortem-style retro even if nothing broke. Begin mentoring a junior on the next slice.

The thread: reduce risk early, deliver measured impact by the end of the quarter, leave the system better-documented than you found it.

6. Questions to ask them (these signal seniority)

• "Where does the data plane / control plane boundary sit today, and what's the config-propagation SLO — how fast and how safely does a change reach the whole fleet?"
• "What's your current strategy for origin connection efficiency — are you on per-event-loop pools and subsetting fleet-wide yet?"
• "For the WebSocket/push tier, how do you drain a node holding hundreds of thousands of connections during a deploy?"
• "How far along is the move onto the Kubernetes Gateway API, and where does Envoy vs the Zuul lineage fit in the target architecture?"
• "What does a large migration look like here operationally — shadow traffic, sticky canaries, automated rollback on SLO breach?"
• "What's the most surprising production failure mode the team has hit in the last year?" (Their answer tells you what you'd actually work on.)

7. The one-page cheat sheet

Print this. Read it in the lobby.

DATA PLANE vs CONTROL PLANE — say it first, always.
NUMBERS — rps, conns/node, config size, change rate. Always quantify.
REQUEST LIFECYCLE — accept→TLS→decode→filters→LB+pool→proxy→filters→log.
FAILURE MODES — retry storms (budgets!), churn (pools+subsetting),
                config thundering-herd (delta+jitter), HOL (h3),
                draining stateful nodes (reconnect+backoff+jitter).
RESILIENCE — P2C LB, zone-aware, outlier ejection, circuit breaker,
             adaptive concurrency (Little's law), load shedding.
SECURITY — mTLS everywhere, SPIFFE/SVID identity, authz at edge.
ROLLOUT — flag → shadow/mirror → sticky canary → ramp → auto-rollback.
DEBUG — scope → golden signals → correlate → walk path → falsifiable
        hypothesis → mitigate then fix.
CULTURE — ownership, context-not-control, highly-aligned/loosely-coupled,
          impact via data, candor.