Phase 6 — Cloud Gateway & Application Networking

Target role: Distributed Systems Engineer 5 — Cloud Gateway, Netflix Application Networking Group.

Phases 1–5 of this book build the systems that live behind a request: storage engines, B-trees, LSM trees, and the consensus protocols that keep replicated state honest. Phase 6 builds the systems that live in front of a request: the L4/L7 data plane, the API gateway, the WebSocket fleet, the control plane that programs them, and the Kubernetes substrate they run on.

This is the same discipline — reliable, scalable distributed systems — pointed at a different layer of the stack. A gateway is a distributed system: it has a data plane (many stateless-ish proxies) and a control plane (a consensus-backed source of truth that pushes config to the fleet). If you understood why Raft commits only current-term entries (db-17) you already understand why an xDS control plane must be careful about config propagation ordering (gw-08). The skills transfer; the vocabulary changes.

Why this phase exists

You have a strong foundation in storage and consensus. The Netflix Cloud Gateway role asks for a different, adjacent body of knowledge that the first five phases do not cover:

How this phase is structured

The 12 labs follow the same shape as the rest of the book — CONCEPTS.md (the 8-part framework), references.md, docs/, and steps/ with runnable code — with one deliberate difference. Phases 1–5 prove correctness with byte-identical cross-language dumps. Networking systems are not byte-deterministic by nature (timers, kernel scheduling, connection ordering), so Phase 6 proves things the way the industry actually does: runnable mini-implementations you can point a load generator at, plus the metrics that tell you whether they work under stress. You will build, in Go (the lingua franca of the cloud-native data plane) with Java/Netty where the Zuul lineage matters:

• a non-blocking L4 TCP proxy with backpressure and connection draining (gw-01),
• an HTTP/2 frame parser and a multiplexing demo (gw-02),
• a filter-chain API gateway in the Zuul 2 shape (gw-03),
• a per-event-loop pooled, subsetted connection manager that reproduces the connection-churn win (gw-04),
• a WebSocket push proxy with a push registry and async delivery (gw-05),
• power-of-two-choices load balancing and an adaptive concurrency limiter (gw-06),
• an xDS control plane that drives Envoy via go-control-plane (gw-08),
• a Kubernetes operator (controller-runtime) that reconciles a Gateway CRD into data-plane config (gw-10),
• trace-context propagation through a proxy and RED dashboards (gw-11).

The talks, decoded

The job posting links seven talks. Read them as a map of what the team values and what you'll be expected to reason about on day one. Each maps to a lab so you can go deep where it counts.

The throughline: this team has spent a decade learning that the expensive failures at the edge are not algorithmic — they are operational. Connection churn, thundering herds on config push, a WebSocket fleet that can't be drained gracefully, a retry storm that turns a brown-out into an outage. The talks are a catalog of hard-won operational lessons. Phase 6 teaches you to reason about them before you cause them.

What "Distributed Systems Engineer 5" actually means at Netflix

Netflix's IC ladder runs Senior (4) → Senior 5 → Staff/Principal. A "5" is expected to:

1. Own a problem domain, not a ticket. "Make origin connections stop churning" is the assignment; you scope it, design it, align stakeholders, ship it, and operate it. (gw-12)
2. Use data to find root cause. The JD says this twice. Every lab's docs/observation.md is written in this spirit: what to measure, how to read it, how to tell correlation from cause.
3. Mentor and set the bar. Design reviews and code reviews are listed as core responsibilities. The docs/analysis.md in each lab is modeled on a design-review document.
4. Lead migrations. Listed as a "plus" but it's the differentiator. gw-12 is a full playbook.

Netflix's culture deck terms you'll hear in interviews and should be ready to speak to: "context, not control" (you'll be given the why, not the how), "freedom & responsibility", "highly aligned, loosely coupled" (the org-design analog of microservices), and "the keeper test." Map your stories to these.

A note on languages

The JD says Java, Go, or C++. In this domain:

• Java/Netty is the Zuul/Pushy lineage. If you interview with the team that owns Zuul, expect Netty event-loop questions (gw-03, gw-05).
• Go is the cloud-native control-plane lingua franca: go-control-plane (Envoy xDS), controller-runtime (operators), most CNI plugins, Kubernetes itself. Phase 6's runnable code is mostly Go for this reason.
• C++ is Envoy's data plane. You won't write Envoy from scratch, but you should be able to read a filter and reason about its buffering and lifecycle (gw-08).

Pick the one you'll be tested in and make the runnable labs idiomatic in it; skim the other two.

Suggested path through Phase 6

gw-01 (L4)  ─→  gw-02 (L7)  ─→  gw-03 (API gateway)
                                     │
        ┌────────────────────────────┼───────────────────────────┐
        ↓                            ↓                            ↓
   gw-04 (conn mgmt)          gw-06 (resilience)           gw-07 (security)
   gw-05 (websockets)
        │
        └──→ gw-08 (Envoy/xDS) ──→ gw-09 (K8s net) ──→ gw-10 (Gateway API/operator)
                                                              │
                                          gw-11 (observability)
                                                              │
                                          gw-12 (migration capstone)

Do gw-01 → gw-03 in order (each builds the vocabulary for the next). After gw-03 the branches are independent; pick by what your interview loop emphasizes. gw-12 assumes all of them.

See the per-lab interview-readiness sections below.

Interview-readiness index

Every CONCEPTS.md in this phase ends with a §7 Interview Talking Points section written specifically for a senior Cloud Gateway loop. For a fast pass before an onsite, read just those eight sections plus:

• gw-00 HITCHHIKERS-GUIDE.md — read this first: the warm-up primer that builds the data-plane/control-plane mental model, the request-lifecycle map, the distributed-systems throughline, and how to use the runnable code.
• gw-00 INTERVIEW.md — the system-design playbook for gateway problems, behavioral-story mapping, the 30-60-90 day plan, and questions to ask them.
• gw-00 references.md — every talk, blog, RFC, and paper that this phase is built on, with one-line "why read it."

Every lab also ships a maintainer-level GUIDE.md (the deep, hands-on companion to its CONCEPTS.md) and real, go test -race-green Go in src/go/. Verify the whole phase with verify-all.sh.