Networking

• Load balancers, reverse proxies (nginx), DNS, TLS/HTTPS, CDNs, VPCs/subnets, firewalls/security groups.

02 Curated reading

• Cloudflare — Learning Center ↗

  optional eng blog 20m — Clear explainers for DNS, CDNs, TLS, reverse proxies.

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

• ▸ Commonly asked senior concept very common What is the difference between an L4 and an L7 load balancer, and when would you use each?

  An L4 (transport-layer) load balancer routes by IP and TCP/UDP port without looking at the payload. It is fast, low-overhead, protocol-agnostic, and preserves the connection — ideal for raw TCP/UDP, very high throughput, low latency, or when you need a static IP (e.g. AWS NLB).

  An L7 (application-layer) load balancer understands HTTP: it can route on hostname, URL path, headers, and cookies, terminate TLS, do sticky sessions, and apply content-based rules (e.g. send /api to one service, /static to another). That intelligence costs a bit more processing (e.g. AWS ALB). Rule of thumb: web/HTTP traffic that needs path/host routing or TLS termination -> L7; non-HTTP, ultra-high-throughput, or static-IP needs -> L4.

  Follow-ups they push on

  • Which layer can do path-based routing, and why can't the other?
  • Where does TLS termination happen in each case?

  Red flag Claiming an L4 load balancer can route by URL path or host header — it never inspects the HTTP payload, so content-based routing requires L7.

  source: Cloudflare — What is load balancing? ↗
• ▸ Commonly asked senior concept very common Walk me through what happens, step by step, when a user types a URL and hits Enter.

  DNS resolution first: the browser checks its cache, then the OS, then a recursive resolver, which walks root -> TLD -> authoritative nameserver to get the IP (often a CDN edge or load balancer IP).

  Then the TCP connection (handshake) to that IP on port 443, and a TLS handshake to negotiate keys and verify the server's certificate so the channel is encrypted. The browser sends the HTTP request; it likely lands on a CDN edge or load balancer, which either serves cached content or forwards to an origin server. The server (behind a reverse proxy / LB, possibly hitting app servers, caches, and databases) returns the response. Finally the browser parses HTML, fetches sub-resources (CSS/JS/images, often from the CDN), and renders. This question is a checklist of the whole stack — name DNS, TCP, TLS, LB/reverse proxy, CDN, and origin.

  Follow-ups they push on

  • Where does the CDN fit, and what does it save you?
  • What does the TLS handshake actually establish before any HTTP is sent?

  Red flag Skipping straight to 'the server returns HTML' and omitting DNS, the TLS handshake, and the load-balancer/CDN hops — the interviewer is probing breadth across the whole networking stack.

  source: Cloudflare — What is DNS? ↗
• ▸ Commonly asked senior concept common How does the TLS handshake work, and what does HTTPS actually give you?

  HTTPS = HTTP over TLS. TLS provides three things: encryption (eavesdroppers can't read traffic), authentication (you're talking to the real server, via its certificate), and integrity (tampering is detected).

  The handshake establishes a shared session key without ever sending it in the clear. The client sends a ClientHello (supported versions/ciphers); the server responds with its choice plus its certificate. The client validates the certificate against a trusted Certificate Authority chain (this is the authentication step). They then perform a key exchange — modern TLS 1.3 uses ephemeral Diffie-Hellman so each session gets a fresh key (forward secrecy: stealing the server's key later can't decrypt past traffic). Once the shared symmetric key is derived, the rest of the session uses fast symmetric encryption. TLS 1.3 also trimmed the handshake to one round trip. The asymmetric crypto is only used to bootstrap the symmetric key.

  Follow-ups they push on

  • What is forward secrecy and why does ephemeral key exchange give it to you?
  • Why switch from asymmetric to symmetric encryption after the handshake?

  Red flag Saying the whole session is encrypted with the server's public/private key pair — asymmetric crypto only bootstraps a shared symmetric key; the bulk traffic uses fast symmetric encryption.

  source: Cloudflare — What happens in a TLS handshake? ↗
• ▸ Commonly asked mid concept common What is a reverse proxy, and how is it different from a forward proxy and a load balancer?

  A reverse proxy (e.g. nginx) sits in front of your servers and faces clients: clients connect to it, and it forwards requests to backends. It centralizes TLS termination, caching, compression, request routing, and security (it hides backend topology and can absorb attacks). The client doesn't know which backend served it.

  A forward proxy sits in front of clients and faces the internet — it proxies outbound requests on behalf of users (corporate egress filtering, anonymity, caching outbound). So the two differ by which side they represent: reverse proxy works for the servers, forward proxy works for the clients.

  A load balancer is a specific job — distributing traffic across multiple backends — that a reverse proxy often performs, but a reverse proxy also does TLS, caching, and routing beyond just balancing. In practice nginx is frequently both reverse proxy and load balancer.

  Follow-ups they push on

  • Which side does each proxy represent — the client or the server?
  • Is every reverse proxy a load balancer? Is every load balancer a reverse proxy?

  Red flag Mixing up forward and reverse proxies — a forward proxy acts on behalf of the client (outbound), a reverse proxy acts on behalf of the server (inbound).

  source: Cloudflare — What is a reverse proxy? ↗
• ▸ Commonly asked mid concept common What does a CDN do, and how does it speed up content delivery?

  A CDN is a globally distributed network of edge servers that cache copies of your content close to users. When a user requests an asset, they're served from the nearest edge location instead of a round trip to a single origin — turning a 100-300ms origin fetch into a 5-20ms edge cache hit and slashing latency for users far from your origin.

  Beyond latency, a CDN offloads traffic from your origin (the origin only serves cache misses, so it handles far less load and survives traffic spikes), and the edge often adds TLS termination, compression, and DDoS protection. It's ideal for static and cacheable content — images, CSS/JS, video, downloads. Dynamic, per-user responses are harder to cache, though edge compute and smart cache keys help. Cache invalidation (knowing when to purge stale content) is the recurring hard part.

  Follow-ups they push on

  • What kinds of content cache well on a CDN, and what doesn't?
  • How does a CDN reduce load on your origin, not just latency?

  Red flag Thinking a CDN only helps latency — it also massively offloads the origin (origin only serves cache misses), which is often the bigger win during traffic spikes.

  source: Cloudflare — What is a CDN? ↗
• ▸ Commonly asked mid concept common What is a VPC, and what's the difference between a public and a private subnet?

  A VPC (Virtual Private Cloud) is your own logically isolated network inside the cloud, with a private IP range you control. You carve it into subnets, each living in one availability zone.

  The public/private distinction is about reachability from the internet, controlled by routing. A public subnet has a route to an internet gateway, so resources there can have public IPs and be reached from the internet — that's where you put load balancers and bastion hosts. A private subnet has no direct internet route inbound; that's where you put app servers and databases so they can't be reached directly. Private-subnet resources still make outbound calls (e.g. to pull updates) through a NAT gateway, which allows egress but not unsolicited inbound. The pattern: internet -> load balancer in a public subnet -> app/database in private subnets.

  Follow-ups they push on

  • How does a private-subnet instance reach the internet for outbound updates?
  • Where would you place a database and why?

  Red flag Putting databases in a public subnet for convenience — they become directly reachable from the internet; databases belong in private subnets behind a load balancer or bastion.

  source: AWS — VPC subnets (public/private) ↗
• ▸ Commonly asked senior concept occasional What is the difference between a security group and a network ACL, and how do they implement defense in depth?

  Both are virtual firewalls in a VPC but operate at different scopes and behave differently. A security group is attached to an instance/ENI and is stateful: if you allow an inbound request, the response is automatically allowed back out — you only write the rules you care about, and you can only specify allow rules.

  A network ACL is attached to a subnet and is stateless: it evaluates inbound and outbound traffic independently (so you must allow the return traffic explicitly), it supports both allow and deny rules, and rules are evaluated in numbered order. So security groups guard individual resources, NACLs guard the whole subnet boundary.

  Using both is defense in depth: the NACL is a coarse subnet-level gate (e.g. block a bad IP range for everything in the subnet) and the security group is the fine-grained per-instance control. An attacker has to get past both layers.

  Follow-ups they push on

  • Why does a stateless NACL require you to allow return traffic explicitly?
  • Why run both instead of relying on just the security group?

  Red flag Treating a security group as stateless and adding redundant outbound rules for return traffic, or assuming a NACL is stateful and forgetting to allow the response, which silently drops connections.

  source: AWS — Compare security groups and network ACLs ↗
• ▸ Commonly asked mid concept very common What is the difference between TCP and UDP, and when would you choose UDP?

  TCP is connection-oriented and reliable: a handshake sets up the connection, then it guarantees ordered, complete, error-checked delivery, retransmitting lost packets and applying flow/congestion control. That reliability costs overhead and latency — the handshake, acks, and head-of-line blocking when a lost packet stalls everything behind it. It's the default for anything that must arrive intact: HTTP, database connections, file transfer.

  UDP is connectionless and 'fire-and-forget': no handshake, no ordering, no retransmission, no congestion control — just send datagrams. It's leaner and lower-latency, but the application must tolerate (or itself handle) loss and reordering. Choose UDP when timeliness beats completeness: live video/voice (a dropped frame is better than a stalled stream), real-time gaming, and DNS (one small request/response where setting up a TCP connection would be wasteful).

  The modern twist: QUIC/HTTP-3 runs over UDP and rebuilds reliability/ordering in userspace to dodge TCP's head-of-line blocking — UDP as a foundation, not a compromise.

  What a strong answer covers

  • TCP: connection + handshake, reliable, ordered, congestion-controlled — HTTP, DBs, file transfer.

  • UDP: connectionless, no ordering/retransmission — lean and low-latency, app handles loss.

  • Choose UDP when timeliness beats completeness: live video/voice, gaming, DNS.

  • TCP's reliability adds latency (handshake, acks, head-of-line blocking on loss).

  • QUIC/HTTP-3 runs on UDP and re-adds reliability in userspace to avoid TCP head-of-line blocking.

  Quick self-check

  For a live voice/video call, why is UDP often preferred over TCP?

  • Dropping a late packet is better than stalling the stream to retransmit it
  • UDP guarantees ordered, lossless delivery
  • UDP encrypts traffic automatically
  • TCP can't carry audio or video data

  Follow-ups they push on

  • Why does a single lost packet in TCP stall everything behind it (head-of-line blocking)?
  • Why does DNS traditionally use UDP for a typical query?
  • How does QUIC get reliability while running over UDP?

  Red flag Calling UDP 'unreliable so never use it' — for latency-sensitive, loss-tolerant traffic (voice, video, gaming, DNS) UDP is the correct choice, and modern protocols like QUIC build on it deliberately.

  source: Cloudflare — What is the difference between TCP and UDP? ↗
• ▸ Commonly asked mid concept common Explain how DNS resolution works end to end, and what the common record types do.

  DNS turns a name into an IP through a hierarchy of caches and authoritative servers. The browser/OS cache is checked first; on a miss, a recursive resolver (your ISP's or e.g. 8.8.8.8) does the legwork: it asks a root server (which points to the right TLD), then the TLD server for .com (which points to the domain's authoritative nameserver), then the authoritative nameserver, which returns the actual record. Results are cached at each level for the record's TTL, so most lookups never travel the full chain.

  Common records: A (name → IPv4) and AAAA (→ IPv6); CNAME (alias one name to another name); MX (mail servers); TXT (arbitrary text — SPF/DKIM, domain verification); NS (delegates a zone to nameservers). TTL is the lever for caching vs agility: a long TTL means fewer lookups but slow propagation when you change records; a short TTL flips that — which is why you lower TTL *before* a planned migration.

  Senior tell: knowing the resolver, not the browser, walks root→TLD→authoritative, and that DNS is a globally cached, eventually-consistent system (TTL governs staleness).

  What a strong answer covers

  • Caches first (browser/OS), then a recursive resolver walks root → TLD → authoritative.

  • Each level caches the answer for its TTL, so most lookups short-circuit.

  • A/AAAA = name→IPv4/IPv6; CNAME = alias to another name; MX = mail; TXT = SPF/verification; NS = delegation.

  • TTL trades caching vs agility — lower it before a migration so changes propagate fast.

  • DNS is globally cached and eventually consistent; stale answers persist until TTL expires.

  Quick self-check

  You're migrating to a new server IP next week and want DNS to cut over quickly. What do you do first?

  • Lower the record's TTL ahead of time so resolvers re-query sooner
  • Raise the TTL so the change sticks
  • Delete the A record entirely the day before
  • Switch the record from A to CNAME

  Follow-ups they push on

  • Why lower a record's TTL before a planned IP migration?
  • What's the difference between an A record and a CNAME?
  • Who actually walks the root→TLD→authoritative chain — the browser or the resolver?

  Red flag Changing a DNS record and expecting it to take effect instantly — old answers stay cached until the TTL expires, so propagation is governed by TTL; you lower TTL ahead of time for fast cutovers.

  source: Cloudflare — What is DNS? / DNS records ↗
• ▸ Commonly asked senior concept common What load balancing algorithms exist, and how do sticky sessions and health checks fit in?

  Common algorithms: round-robin (rotate through backends — simple, assumes roughly equal requests/servers); least-connections (send to the backend with the fewest active connections — better when request durations vary widely); weighted variants (bias toward bigger instances); and hash-based (e.g. hash the client IP or a key to pin a client consistently to one backend).

  Health checks are what make a load balancer safe: it periodically probes each backend and stops routing to any that fail, so a dead or unhealthy instance is automatically taken out of rotation and traffic flows only to healthy ones. Without them the LB cheerfully sends traffic into a black hole.

  Sticky sessions (session affinity) pin a given client to the same backend (via a cookie or IP hash) so server-local session state keeps working. It's a crutch: it undermines even load distribution and breaks when that backend dies. The senior view is to avoid the need for it by making services stateless and externalizing session state to a shared store (Redis), so any backend can serve any request and the LB is free to balance optimally.

  What a strong answer covers

  • Algorithms: round-robin, least-connections (varied request durations), weighted, hash-based.

  • Health checks remove failed backends from rotation — without them the LB routes into dead servers.

  • Sticky sessions pin a client to one backend so server-local state works — but it's a crutch.

  • Stickiness undermines even balancing and breaks when the pinned backend dies.

  • Better: stateless services + shared session store (Redis) so any backend serves any request.

  Follow-ups they push on

  • When is least-connections a better choice than round-robin?
  • Why do sticky sessions undermine even load distribution?
  • How does externalizing session state let you drop sticky sessions?

  Red flag Relying on sticky sessions to hold user state on a specific server — when that server is removed (scale-in, failure, deploy) the session is lost; externalize session state so any backend can serve the request.

  source: Cloudflare — What is load balancing? ↗
• ▸ Commonly asked senior concept occasional What is HTTP/2 (and HTTP/3), and what problems did they solve over HTTP/1.1?

  HTTP/1.1 sends one request/response per connection at a time; a slow response blocks the ones behind it on that connection (head-of-line blocking), so browsers worked around it by opening many parallel connections — wasteful and still limited.

  HTTP/2 introduced multiplexing: many requests/responses share one TCP connection as interleaved streams, so a slow response no longer blocks others *at the HTTP layer*. It also added header compression (HPACK) and stream prioritization. But because it still rides on a single TCP connection, a lost TCP segment stalls *all* streams — TCP-level head-of-line blocking remained.

  HTTP/3 fixes that by moving off TCP onto QUIC (over UDP): streams are independent at the transport layer, so one lost packet only stalls its own stream, not the others. QUIC also folds the transport + TLS handshake together for faster (often 0-1 RTT) connection setup and better mobility across networks. The arc: HTTP/2 solved app-layer HOL blocking, HTTP/3 solved transport-layer HOL blocking.

  What a strong answer covers

  • HTTP/1.1: one in-flight request per connection → app-layer head-of-line blocking, many parallel sockets.

  • HTTP/2: multiplexes many streams on one TCP connection + header compression (HPACK).

  • HTTP/2's flaw: still one TCP connection, so a lost segment causes transport-level HOL blocking.

  • HTTP/3 runs on QUIC over UDP — independent streams, so one lost packet stalls only its stream.

  • QUIC also merges transport+TLS handshake for faster (0-1 RTT) setup and connection migration.

  Quick self-check

  What was the key transport change in HTTP/3 versus HTTP/2?

  • It runs over QUIC (UDP) so streams are independent and don't share TCP head-of-line blocking
  • It reintroduced one connection per request like HTTP/1.1
  • It dropped encryption to go faster
  • It replaced HTTP semantics with a binary RPC protocol

  Follow-ups they push on

  • Why does HTTP/2 still suffer head-of-line blocking despite multiplexing?
  • How does running over QUIC/UDP let HTTP/3 avoid that?
  • What did header compression (HPACK) buy HTTP/2?

  Red flag Claiming HTTP/2 eliminated head-of-line blocking entirely — it removed it at the HTTP layer, but a single lost TCP packet still stalls all streams; only HTTP/3 over QUIC removes the transport-level HOL blocking.

  source: Cloudflare — What is HTTP/3? ↗
• ▸ Commonly asked mid concept occasional What is a TLS/SSL certificate, who issues it, and how does a browser decide to trust it?

  A certificate binds a public key to an identity (a domain name) and is signed by a Certificate Authority (CA). When you connect, the server presents its certificate during the TLS handshake; the browser verifies the CA's signature, walks the chain of trust up to a root CA that's pre-installed in the OS/browser trust store, and checks the cert isn't expired, matches the hostname, and hasn't been revoked. If all that holds, the browser trusts that it's really talking to that domain (this is the authentication part of TLS).

  The chain matters: a root CA signs intermediate CAs, which sign your leaf certificate, so the server sends leaf + intermediates and the browser anchors trust at the root it already trusts. A self-signed cert isn't signed by a trusted CA, so browsers warn — fine for internal/dev, not for public sites. Today most public certs come from Let's Encrypt (free, automated via ACME) and are short-lived, renewed automatically.

  Senior tell: trust is anchored in pre-installed root CAs and verified via the signature chain — not 'the browser checks the cert with the website'.

  What a strong answer covers

  • A cert binds a public key to a domain identity, signed by a Certificate Authority.

  • Browser verifies the chain of trust up to a root CA in its pre-installed trust store.

  • It also checks expiry, hostname match, and revocation before trusting.

  • Chain: root CA → intermediate(s) → leaf; the server sends leaf + intermediates.

  • Self-signed = not CA-trusted (browser warns); public certs now mostly Let's Encrypt via ACME.

  Follow-ups they push on

  • Why does a self-signed certificate trigger a browser warning?
  • What is the chain of trust, and where is it anchored?
  • Why are automated, short-lived certs (Let's Encrypt/ACME) now the norm?

  Red flag Thinking the browser validates a certificate by checking with the website itself — trust is anchored in pre-installed root CAs and verified through the signature chain; the site never gets to vouch for its own identity.

  source: Cloudflare — What is an SSL certificate? ↗
• ▸ Commonly asked senior debug occasional Users intermittently get 502/504 errors from your service behind a load balancer. How do you debug it?

  First decode the codes: a 502 Bad Gateway means the load balancer got an invalid/empty response from a backend; a 504 Gateway Timeout means the backend didn't respond within the LB's timeout. Both point *downstream of the LB* — the LB is reachable, so the problem is the backends or the path to them, and 'intermittent' suggests some backends or some requests, not all.

  Work it methodically: (1) check backend health in the LB — are some targets failing health checks and flapping in/out of rotation? (2) backend logs/metrics — crashes, restarts, OOM, or slow endpoints (504 often = a slow query or a downstream dependency timing out). (3) timeout mismatch — a classic 502 cause is the LB's idle/keep-alive timeout being *longer* than the backend's, so the backend closes a connection the LB still tries to reuse; align them (backend keep-alive ≥ LB idle timeout). (4) capacity — are 5xx spikes correlated with load (saturated backends, exhausted connection pools, thread starvation)? (5) recent deploys/config changes.

  Senior tell: distinguishing 502 (bad/empty upstream response, often the keep-alive timeout mismatch) from 504 (upstream too slow), and following the request path from LB → backend → that backend's dependencies.

  What a strong answer covers

  • 502 = LB got an invalid/empty response from a backend; 504 = backend timed out — both downstream of the LB.

  • Check backend health checks — flapping targets cause intermittent failures.

  • Inspect backend logs/metrics: crashes, OOM, slow endpoints, dependency timeouts (typical 504).

  • Classic 502: LB idle timeout > backend keep-alive, so the backend drops a connection the LB reuses — align them.

  • Correlate 5xx with load (saturated pools/threads) and recent deploys.

  Follow-ups they push on

  • What's the difference in meaning between a 502 and a 504?
  • How does a keep-alive/idle timeout mismatch produce intermittent 502s?
  • Why does 'intermittent' point you toward specific backends or load rather than the LB itself?

  Red flag Blaming the load balancer for 502/504s — both codes mean the LB reached the backend but the backend gave a bad or slow response; the fix is almost always in the backends, their dependencies, or a timeout mismatch, not the LB config alone.

  source: Cloudflare — What is a 502 Bad Gateway error? ↗