The Hitchhiker's Guide to the Cloud Gateway

A warm-up primer for Phase 6. Read this first. It builds the mental model the whole phase hangs on, shows you how to use the runnable code, and gives you the throughline that turns twelve labs into one coherent story you can tell in an interview.

Don't panic. By the end of this phase you will have built — in real, tested, runnable Go — an L4 proxy, an HTTP/2 parser, a Zuul-shaped API gateway, Netflix's connection-churn fix, a Pushy-style WebSocket fleet, the full resilience toolkit, an mTLS gateway, an xDS control plane, a Kubernetes operator, the observability primitives, and a migration rollout engine. Every bash scripts/verify.sh is green.

1. The one idea that unlocks everything: data plane vs control plane

A cloud gateway is not one program; it's two systems with opposite goals, and almost every design question resolves once you name which one you're talking about.

            CONTROL PLANE  (correctness-optimized, OFF the request path)
        ┌───────────────────────────────────────────────────────┐
        │  source of truth → reconcile → versioned config         │
        │            │  push (xDS / operator)                      │
        └────────────┼──────────────────────────────────────────┘
                     ▼
            DATA PLANE  (p99/throughput-optimized, ON the request path)
   client ──▶ [ L4 → TLS → L7 decode → filters → LB+pool → proxy → log ] ──▶ origins

• The data plane is the fleet of proxies on the request path. It is optimized for p99 latency, throughput, and availability. It must keep serving even when the control plane is down (it runs on last-known-good config). gw-01, gw-02, gw-03, gw-04, gw-05, gw-06, gw-07 are all data-plane.
• The control plane is the source of truth that computes config and pushes it to the fleet. It is optimized for correctness and safe propagation, not latency. Its outage stops config changes, not traffic. gw-08 and gw-10 are control-plane; gw-11 observes both; gw-12 changes both safely.

Say "I'll split this into a data plane and a control plane" in the first 60 seconds of any gateway design interview. It is the single highest-signal move you can make, and the rest of this phase is the detail behind it. (See INTERVIEW.md for the full playbook.)

2. The request lifecycle (and which lab owns each hop)

Trace one request through an L7 gateway and you've toured the whole phase:

accept the TCP connection .................... gw-01 (L4: sockets, backpressure, drain)
terminate TLS / verify mTLS identity ......... gw-07 (mTLS, SPIFFE, rotation)
decode the protocol (HTTP/2 frames, gRPC) .... gw-02 (L7 framing, HPACK, flow control)
run inbound filters: authn, route, rate-limit  gw-03 (the Zuul filter chain)
pick an origin: LB over a pooled subset ...... gw-04 (pooling+subsetting) + gw-06 (P2C)
proxy with resilience: timeout/retry/breaker.. gw-06 (retries, circuit breaker, adaptive)
run outbound filters: rewrite, access log .... gw-03 + gw-11 (RED metrics, trace span)
                            ▲
   the proxies above RUN ON Kubernetes ........ gw-09 (CNI, kube-proxy, drain ordering)
   their config is PUSHED by a control plane .. gw-08 (xDS) / gw-10 (operator)
   and CHANGES ship via a rollout ladder ...... gw-12 (shadow → canary → ramp)

If you can narrate that lifecycle and name where each concern lives, you can hold a Cloud Gateway systems-design round.

3. The distributed-systems throughline (why your db-* work transfers)

Phases 1–5 built storage and consensus. Phase 6 looks different but is the same discipline pointed at a new layer. The connections are real, not rhetorical:

• Backpressure is one idea at three layers. TCP's receive window (gw-01), HTTP/2's flow-control credits (gw-02), and your proxy's bounded copy buffer (gw-01) are all "slow the producer when the consumer can't keep up." Adaptive concurrency (gw-06) is the same idea as admission control.
• Config propagation is a consistency problem. An xDS control plane pushing versioned, ACK'd config to a fleet (gw-08) has the same hazards as committing a replicated log (db-17): ordering (ADS exists for the same reason Raft cares about log order), versioning, and acknowledgment. Last-known-good is the data plane's "the cluster keeps serving during an election."
• Reconciliation is the consensus mindset at the app layer. A Kubernetes operator (gw-10) converging actual→desired state, level- triggered and idempotent, is "drive the system to a replicated desired state, safely, no matter the intermediate failures."
• Quorum/majority intuition shows up in subset sizing. "How big must a gw-04 subset be to survive losing f origins?" is db-17's majority argument.
• Determinism is your test oracle. The db-* labs proved correctness with byte-identical dumps; Phase 6 proves it with content-hash versioning (gw-08, gw-10), deterministic simulations (gw-06, gw-09, gw-12), and seeded RNGs (gw-04, gw-06) so every test is reproducible.

You are not learning a new field. You are applying the same rigor to the front door instead of the back room.

4. How Phase 6 is built (and why it differs from Phases 1–5)

Phases 1–5 prove correctness with byte-identical cross-language dumps (Rust/Go/C++). Networking systems aren't byte-deterministic — timers, kernel scheduling, connection ordering — so Phase 6 proves things the way the industry actually does: runnable mini-implementations you can point load at, plus the metrics that show they work under stress.

Concretely, every lab gw-NN ships:

gw-NN-name/
├── CONCEPTS.md      # the 8-part framework (the "why")
├── GUIDE.md         # the deep, hands-on companion (read with the code open)
├── references.md    # papers, RFCs, the Netflix talks, source to read
├── docs/
│   ├── analysis.md      # design-review-style trade-offs
│   ├── execution.md     # how to build/run
│   └── verification.md  # what "green" proves (and doesn't)
├── steps/           # staged, code-rich implementation guides
├── scripts/verify.sh    # builds + vets + tests (offline, stdlib-only)
└── src/go/          # REAL, COMPILABLE, TESTED Go — the thing you hack on

The code is stdlib-only Go (the cloud-native data-plane lingua franca), so it builds and tests offline with zero dependencies — exactly like the db-* labs. Where the Zuul/Pushy lineage matters, the GUIDE points at the Java/Netty equivalents. Each verify.sh runs go test -race and (where there's one) a demonstration program that prints the lab's headline result.

How to work a lab: read CONCEPTS.md for the why → open GUIDE.md next to src/go/ and read the code it walks you through → run bash scripts/verify.sh and read the test names (they're the spec) → run the demo CLI → do the exercises at the end of the GUIDE. The exercises are the interview.

5. The headline results you can reproduce

These are the "you won't find this in a book" moments — run them:

6. The seven talks, as your study map

The JD links seven talks. They are not background reading — they are the exact problems this team works on, and each maps to a lab whose code you can run:

Watch each talk, then read the matching GUIDE with the code open. You'll recognize every system they describe, and you'll have built a miniature of it.

7. Suggested path

gw-01 (L4) ─▶ gw-02 (L7) ─▶ gw-03 (API gateway)        [do these in order]
                                  │
        ┌─────────────────────────┼──────────────────────────┐
        ▼                         ▼                           ▼
   gw-04 (conn mgmt)       gw-06 (resilience)          gw-07 (security)
   gw-05 (websockets)
        │
        └─▶ gw-08 (xDS) ─▶ gw-09 (K8s net) ─▶ gw-10 (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 the rest.

To verify the entire phase at once:

for d in gw-0*/ gw-1*/; do [ -f "$d/scripts/verify.sh" ] && (echo "== $d ==" && bash "$d/scripts/verify.sh" >/dev/null && echo OK); done

Now go read gw-01's CONCEPTS and GUIDE. The floor of the stack is a socket and two file descriptors — start there.