3) Internet & networking fundamentals — detailed guide

• Flow: client → recursive resolver → authoritative nameserver → answer.
  Recursors cache answers by TTL. Authoritative servers control routing policies (geo/weighted) and record types.
• Records: A/AAAA, CNAME, TXT, MX, SRV, CAA.
  In interviews, name a couple (A/AAAA/CNAME) and mention TXT (verification) + CAA (cert constraints).
• TTL trade-off: low TTL helps steering/failover; high TTL improves stability.
  You can use low TTL during incidents or migrations, and a moderate TTL during steady-state.
• Gotchas: apex CNAME limitations; split-horizon DNS (internal vs external).
  Use ALIAS/ANAME/flattening at apex. Use internal zones for service discovery and private endpoints.

• Layers: browser → CDN edge → reverse proxy → Redis → DB buffer cache.
  Know which layer is responsible for which content: media/static at CDN; personalized APIs often bypass CDN but still benefit from edge routing.
• Cache keys: path + query + Vary headers (Accept-Encoding; sometimes cookies/auth).
  Incorrect keys can leak user-specific content. Always call out Vary and auth boundaries.
• Policies: TTL, stale-while-revalidate, origin shielding, signed URLs.
  Origin shield reduces thundering herds. SWR smooths p95 by serving stale while refreshing.
• Invalidation: purge on write; versioned assets for immutable caching.
  Prefer versioned static assets (content-hash filenames) so you avoid frequent purges.

• HTTP/1.1: limited multiplexing; keep-alive helps; TCP HOL affects concurrency.
  Still common, but chatty pages benefit from HTTP/2/3.
• HTTP/2: multiplex streams on one TCP connection, header compression; great for many small requests.
  Also foundational for gRPC.
• HTTP/3 (QUIC): multiplex without TCP HOL; better on mobile; faster resume.
  Great for flaky networks and mobility; mention measuring impact rather than assuming.

• DNS steering: www.facebook.com resolves to an Anycast CDN/WAF VIP; moderate TTL (minutes) for stability.
  During incidents/migrations, TTL can be reduced temporarily to accelerate steering/failover.
• Anycast edge: users hit a nearby POP for low latency and resilience.
  POP also absorbs DDoS and reduces cross-region latency for first byte.
• CDN caching: images/videos are served from CDN with signed URLs; feed API returns metadata + media URLs.
  This pushes the heavy bytes (media) to the edge while keeping personalized feed reads fast and small.
• HTTP/2/3 at the edge: multiplexing helps feed scroll (many small requests) and improves mobile experience.
  Net result: better p95 for repeated feed refresh + faster image loads on unstable networks.

• Edge termination: TLS ends at CDN/WAF/LB; re-encrypt to origin.
  Centralizes cert management and enables L7 features (WAF, routing). Re-encrypt inside for defense-in-depth.
• Passthrough: TLS terminates at the service (rare; compliance/special protocols).
  Less L7 visibility at the LB. Requires strong service-level observability and rotation automation.

• What: both sides present certificates (cryptographic identity).
  Common with service mesh/SPIFFE. Still pair with app-layer authZ.
• Where: service-to-service inside clusters; B2B APIs that require client certs.
  Mention rotation and SAN/issuer validation as first-class requirements.

• ALB / L7 proxy: host/path routing, WAF, richer health, HTTP retries, auth offload, gRPC/websockets.
  Best for HTTP APIs and gradual rollouts (canary by headers).
• NLB / L4: raw TCP/UDP, preserves source IP, low overhead.
  Use for custom protocols, high throughput TCP, or when you want minimal proxy behavior.
• K8s Ingress/Gateway: controller implements L7 rules and routes to services.
  Ingress is north-south; service mesh can handle east-west with mTLS, retries, circuit breakers.

• TLS termination: TLS terminates at CDN/WAF; origin traffic is re-encrypted to the regional ingress/L7 LB.
  Centralized cert management at the edge + secure hop to origin prevents plaintext inside networks.
• L7 routing: edge forwards to L7 (ALB/Ingress) for host/path routing: /api/feed, /api/posts.
  L7 also supports canary routing (headers/percent) and consistent health checks.
• mTLS internally: service-to-service calls (FeedReadSvc → PostSvc → UserSvc) use mTLS identity.
  Rotation is automated (mesh/SPIFFE). AuthZ still happens at each service boundary.
• L4 where needed: for high-throughput TCP (if any) or specialized streaming paths, an L4 LB can be used.
  But for most feed APIs, L7 is the default due to routing and observability needs.

• Round Robin / Weighted RR
  Simple distribution; good default for homogeneous fleets.
• Least Connections / Least Pending
  Better when requests have variable duration.
• EWMA / Least Time
  Route around slow hosts; helps p95/p99.
• Consistent Hashing
  Sticky by key (userId/session) for cache locality.
• Power of Two Choices
  Scalable load-aware routing with low overhead.

• Active health: readiness vs liveness; dependency-aware checks.
  Readiness gates traffic during deploys; liveness restarts dead processes.
• Passive health: outlier ejection on 5xx/latency spikes.
  Prevents one bad host from poisoning p95/p99.
• Connection lifecycle: slow-start for new pods, draining for old pods, tuned keep-alives.
  Avoids cold-start spikes and reduces dropped requests on rollouts.

• Traffic: feed reads are read-heavy and tail-sensitive; peak can be very high (e.g., ~111,111 RPS at ×6 multiplier).
  This is why you care about outlier ejection and queue control at the LB and service layers.
• Routing: L7 routes /feed to FeedRead fleet; /posts to PostWrite fleet; rate limits are stricter on writes.
  Separating read/write paths simplifies scaling and protects the read SLO during spikes.
• Algorithm: EWMA/least-time for stateless feed APIs; consistent hashing when you want cache affinity (e.g., session → warm cache).
  Avoid client-IP stickiness because many users sit behind NAT or mobile carrier gateways.
• Deploy safety: slow-start new pods + draining old ones prevents p95 spikes during rolling deploys.
  Readiness checks ensure a pod is actually ready (warm caches, loaded models) before taking traffic.

• Public subnets: internet gateway route; host public LBs/NAT.
  Keep application services in private subnets; only controlled entry points are public.
• Private subnets: no public inbound; inbound via LBs; outbound via NAT.
  Databases and services belong here in most designs.
• Security: security groups (stateful) + NACLs (stateless) + least-privilege egress.
  Treat egress as a security boundary; monitor and restrict destinations.

• Internet egress: NAT gateway + outbound proxy; allow-list partner CIDRs/domains.
  Watch NAT connection/port metrics; reduce connection churn with keep-alive and pooling.
• Private access: VPC endpoints / PrivateLink to reach managed services without public IPs.
  Reduces egress cost and avoids IP allowlist drift for SaaS dependencies.
• Hybrid: VPN/DirectConnect; avoid CIDR overlap; route via transit gateway.
  CIDR planning early prevents painful renumbering later.

• Private services: FeedReadSvc/PostWriteSvc in private subnets; only ALB/Ingress is public.
  This limits blast radius and reduces attack surface while keeping the user entry point controlled.
• Outbound: services call 3rd-party dependencies through NAT/proxy with allow-listed egress (and strong observability).
  If NAT saturates (connections/ports), shard NAT, use private endpoints where possible, and reduce connection churn.
• Media: object store origins are accessed over provider backbone; CDN pulls from shield POP/origin with tight rules.
  This is how you keep media delivery reliable without exposing storage directly to the internet.

“Home Feed: DNS → Anycast CDN/WAF (TLS) → ALB/Ingress (L7 routing + health) → Feed services in private subnets (mTLS). CDN serves media with signed URLs; outbound through NAT/proxy with allow-listed egress; HTTP/2/3 at the edge.”

• Wrong cache key / missing Vary: data leaks or poor hit ratio.
  For personalized feeds, be explicit: you usually don’t CDN-cache responses unless you design a private cache key (and accept complexity).
• Timeouts too long: retry storms and tail latency blowups.
  Layer timeouts per hop and keep retry budget within SLO. Retry only idempotent reads; use idempotency keys for writes.
• Sticky by client IP: breaks behind NAT/mobile and causes hot backends.
  Use cookies or consistent hashing on session/userId if stickiness is needed for cache locality.
• NAT saturation: port exhaustion / connection tracking bottlenecks.
  Monitor NAT metrics; shard egress and reduce churn; prefer private endpoints for cloud services.
• mTLS rotation pain: manual cert updates cause outages.
  Automate with mesh/SPIFFE. Short-lived certs and continuous rotation.

1) Check CDN hit ratio for media + cache key correctness (Vary, signed URLs)
2) Validate L7 health checks, slow-start, draining (deploy spikes hurt feed p95)
3) Audit timeouts/retries budgets (avoid retries amplifying peak)
4) Inspect NAT metrics/flow logs for outbound bottlenecks
5) Verify mTLS rotation automation and failure modes