Networking Patterns

Six patterns that underlie every network: routing-and-addressing, load-balancing, service-discovery, network-policy, service-mesh, and zero-trust-networking.

Six patterns from the network stack and the mesh layer. Touched in Y3 Phase 18; deepens through Y3 Phase 25 (mesh) and Y3 ongoing operation.

Patterns in this category

PatternFirst touchedDEEP target
routing-and-addressingY3 Phase 18Y3 Phase 25 (mesh routing)
load-balancingY3 Phase 18Y3 end (Cilium L4/L7)
service-discoveryY3 Phase 20 (K8s)Y3 end
network-policyY3 Phase 25Y3 end (Cilium NetworkPolicy operational)
service-meshY3 Phase 25Y3 end (Cilium Mesh + mTLS)
zero-trust-networkingY3 Phase 25 + Y3 Phase 27Y3 end

Why this category exists

Networking patterns survive the protocol churn. Routing-and-addressing is the abstraction that lets IPv4, IPv6, and overlay networks all be reasoned about uniformly. Load-balancing is the pattern under L4 LBs, L7 LBs, service mesh sidecars, and DNS-based load balancing. Service discovery is what every distributed system needs; Kubernetes, Consul, eBPF-based discovery, and DNS-SD are all instantiations. Network policy is the declarative-allow-list pattern at the network layer. Service mesh is mediation applied to east-west traffic. Zero-trust-networking is the deny-by-default policy that assumes every flow is hostile until proven otherwise.

The category is scoped to platform-relevant patterns. Protocol details (TCP handshake internals, TLS handshake internals, HTTP/3 QUIC framing) live in the phase docs where they’re first taught, not in the pattern library. The library covers pattern level: what problem the layer solves, what trade-offs any solution makes. A pattern-fluent engineer can pick up QUIC in a week because they understand what “reliable ordered delivery with retransmission” means; a tool-fluent engineer redoes the TCP-vs-QUIC learning every time a new protocol lands.

By Y3 end, basecamp runs Cilium Mesh + Hubble + NetworkPolicies between every pod. The patterns are operational, not theoretical. Every pod-to-pod flow is authenticated with mTLS, allow-listed by NetworkPolicy, and observable through Hubble flow logs.

How to read this category

Two patterns are network-fundamentals (Phase 18). Four are platform-networking (Phases 20-27).

Fundamentals (Phase 18): routing-and-addressing and load-balancing. Both first-fire during networking-deep. Read the STUB entries before Phase 18. Promote to OUTLINE during the phase. These are the patterns you carry through the rest of the program.

Kubernetes networking (Phase 20): service-discovery first-fires as ClusterIP + DNS + kube-proxy. The pattern gets first-touched almost immediately when you deploy the first workload.

Mesh triad (Phase 25): network-policy, service-mesh, zero-trust-networking. These three fire together at Phase 25. Read all three STUB entries before starting the phase. All three go DEEP by end of Y3 through operating Cilium in production.

Cross-cutting: zero-trust-networking returns at Phase 27 (secrets and defense-in-depth). It’s the framing that connects network-layer isolation to identity-layer authorization.

How the patterns connect

The six patterns nest in a stack.

  • routing-and-addressing is the base layer. Every packet has to get somewhere; this is the pattern for how.
  • load-balancing sits above routing. Given N destinations that all satisfy the routing constraint, which one gets the packet? Round-robin, least-connections, consistent-hashing are all algorithms within this pattern.
  • service-discovery operates above load-balancing. How does a caller find the current set of destinations at all? DNS, Consul, K8s Endpoints, and eBPF-based discovery are all instantiations.
  • network-policy is the discovery-layer allow-list. Given service discovery works, network-policy answers “which of the discovered destinations is this caller allowed to reach?”
  • service-mesh sits above the four base patterns. Mesh applies routing, load-balancing, discovery, and policy uniformly across every east-west flow, plus adds observability and mTLS.
  • zero-trust-networking is the composition rule that says every layer above must default-deny and require explicit permission. It’s not a separate mechanism; it’s how the other five patterns are configured together.

Where these show up in /root

  • Y3 Phase 17 — packets and namespaces (netns) as the kernel’s implementation of network isolation.
  • Y3 Phase 18 — routing-and-addressing and load-balancing first-fire through TCP/IP fundamentals, iptables NAT, and haproxy or nginx as classical L4/L7 LBs.
  • Y3 Phase 19 — netns + veth pairs + bridges become concrete when you build containers from scratch. Every namespace has its own routing table; every veth pair is a mini-cable.
  • Y3 Phase 20 — service-discovery first-fires. Kubernetes Service resources abstract routing + load-balancing + discovery into one API object. kube-dns or CoreDNS surface the discovered endpoints.
  • Y3 Phase 24 — multi-cloud brings cross-region routing and cross-cloud DNS into scope. The load-balancing pattern deepens as you handle failover between AWS and GCP.
  • Y3 Phase 25 — the mesh phase. network-policy, service-mesh, zero-trust-networking all first-fire. Cilium replaces kube-proxy for load-balancing, adds Hubble for observability, enforces NetworkPolicies at the L3/L4 layer and CiliumNetworkPolicies at the L7 (HTTP-aware) layer, and provides mTLS between every pod.
  • Y3 Phase 27 — zero-trust-networking returns. The mesh’s mTLS composes with Vault-issued secrets and OIDC-based service identity. Zero trust becomes the whole platform’s posture, not just the network layer’s.

By end of Y3, every basecamp workload is discoverable via K8s Services, load-balanced by Cilium, allow-listed by NetworkPolicy, encrypted in transit by mTLS, and observable through Hubble flow logs.

Anti-patterns

Anti-patternWhy
Promoting service-mesh to DEEP after only reading Istio docsIstio and Cilium mesh implement the same pattern with very different trade-offs. DEEP requires operating at least one and reading the design of at least one other. Docs alone don’t produce pattern fluency.
Skipping the routing-and-addressing STUB because “K8s does it”Kubernetes hides routing behind Services and NetworkPolicies. When something breaks, the abstraction leaks and you need the underlying routing model. Not knowing IPv4 subnets or how kube-proxy IPtables rules work is where 3am debugging goes badly.
Applying network-policy without a deny-all defaultNetworkPolicy that only allow-lists specific flows without a deny-all base is a broken lock. Any pod without a matching NetworkPolicy is unconstrained. Deny-all first, then allow-list.
Zero-trust as a marketing claimZero-trust means every flow is authenticated and authorized. If your mesh does mTLS but not L7 authorization, you have half of zero-trust. If your policy is name-based but not identity-based, you have theatrical zero-trust.
Load-balancing algorithm chosen by defaultRound-robin is the default and it’s wrong for most workloads. Long-lived connections (gRPC, WebSocket) need least-connections or consistent-hashing. Chosen defaults come with debugging costs later.
Service discovery cached in application codeApplications that cache the DNS resolution or the Service Endpoints break the moment pods restart. Let the discovery mechanism refresh; don’t build a second cache on top of it.

Cross-references