TCP, DNS, HTTP — what actually travels the wire

In mock system design rounds, the candidate's first answer to a latency problem is almost always "add a cache" or "put a load balancer in front." And the question that has to follow every time is: "okay, but what is actually happening on the network before your code even runs?" That question breaks people. Not because they do not know networking — most do, somewhere — but because they have never practiced saying it out loud under pressure.

In the StrongYes company corpus alone, Cloudflare and Fortinet make DNS, TLS, CDNs, and network protocols explicit, VMware leans on distributed networking, Vercel expects web-infrastructure depth, and Twitter/X mixes networking fundamentals into systems-flavored coding rounds. DesignGurus' networking interview guide covers the full scope from basic TCP/UDP through modern CDN and Kubernetes networking — worth reviewing as a breadth check.

Networking questions usually sit alongside API Design Interview Questions in the systems corner of the loop. They go badly when candidates jump straight to "use a load balancer" without explaining what the network path is actually doing.

What interviewers are actually testing

A strong networking answer usually proves five things:

1. You can trace how data moves from client to server and back.
2. You know which layer owns which job: transport, application, proxy, cache, or client.
3. You can connect protocol choices to latency, reliability, and failure.
4. You understand why retries, timeouts, and connection reuse change behavior.
5. You can reason from a user-visible symptom instead of naming infrastructure at random.

Interviewers trust candidates more when they say "the failure is probably before the application sees the request" than when they list protocol acronyms without a diagnosis.

The six networking question families that keep repeating

1. TCP vs UDP and when the trade-off matters

• TCP gives ordered, reliable byte-stream delivery with connection state
• UDP gives lower-overhead datagrams without built-in reliability or ordering

The interview point is not the textbook definition. It is why you would choose one over the other. DesignGurus puts it well: "TCP trades some speed for dependability, while UDP trades a bit of dependability for speed" — choosing between them is an architecture decision, not a trivia answer.

I have seen candidates lose this point by saying "UDP is faster" and stopping. The interviewer always follows up: faster for what contract? The strong answer names the specific reliability trade-off:

• "I would use TCP when correctness depends on reliable ordered delivery."
• "I would consider UDP when latency matters more than perfect delivery and the application can tolerate or repair loss."
• "Real-time voice, gaming, or telemetry may accept loss differently than payments or API traffic."

2. DNS, TLS, and the request path before your app runs

Many candidates explain the app but skip the path to the app.

For a normal web request, the useful mental model is this lifecycle — and you should be able to trace every step:

Diagram

Copy source

Rendering diagram...

The what-happens-when repository (43K GitHub stars, CC0 licensed) documents every step from physical keypress through DNS, ARP, TCP, TLS, HTTP, and browser rendering — the canonical reference for this question family.

If the prompt is about latency, outages, or debugging, interviewers want to hear where time can be spent before the application code even starts:

• DNS resolution
• connection setup
• TLS negotiation
• proxy or load-balancer routing

At Cloudflare- or Vercel-shaped companies, "the server is slow" is often the wrong first diagnosis. I bring this up in every system design coaching session: trace the path first, diagnose second.

3. HTTP semantics, retries, and idempotency

Networking questions often turn into API-behavior questions on purpose.

You should be able to explain:

• why GET should be safe to retry
• why POST can create duplicate side effects without protection
• why status codes and timeouts affect client behavior
• why keep-alive or connection reuse changes latency

The interviewer usually wants to see whether you understand that a flaky network can make the same logical request happen more than once. The AWS Builders Library explains this precisely: a unique caller-provided idempotency token lets both service and client recognize duplicate requests without returning misleading errors like "ResourceAlreadyExists." AlgoMaster's idempotency guide covers the same pattern in a system design interview context.

Good language sounds like:

• "A timeout does not tell me whether the server never processed the request or processed it and the response was lost."
• "If the client retries writes, I need idempotency on the server side."

That is where networking naturally connects to API Design Interview Questions.

4. Load balancers, reverse proxies, and CDNs

This family checks whether you know what these components actually do.

• a load balancer distributes traffic across instances
• a reverse proxy sits in front of services and can terminate TLS, route traffic, or enforce policy
• a CDN caches content close to users and reduces origin load and latency — Cloudflare's CDN reference architecture shows how anycast routing and tiered caching topologies work in production

The useful interview move is to connect each piece to the workload:

• is the traffic mostly static or dynamic?
• does session state matter?
• do we need sticky behavior or should the app stay stateless?
• is the bottleneck origin load, geographic distance, or burst traffic?

If you say "put a CDN in front" without naming what is cacheable, the answer feels fake.

5. Latency, throughput, and connection management

This family separates candidates who can reason from symptoms.

You do not need to become a packet-capture expert. You do need to explain the difference between:

• low throughput and high latency
• slow first request and warm reused connections
• local server speed and network round-trip cost
• bandwidth problems and request-count problems

Useful sentence starters:

• "The payload size is small, so I would look at round trips before raw bandwidth."
• "If every request opens a fresh connection, handshake overhead may dominate."
• "If the client is far from the origin, caching or edge delivery may help more than optimizing one database query."

That is the level interviewers usually want.

6. Failure modes: packet loss, retries, and partial outages

This is where senior answers usually get stronger.

A networking answer feels unfinished if it never mentions:

• timeouts
• retries with backoff
• packet loss or flaky links
• connection exhaustion
• partial failures between services

The strong version sounds like:

• "I would define the normal request path, then the first failure I expect."
• "I would avoid retry storms by bounding retries and backing off."
• "I would treat upstream calls as partial-failure boundaries, not as if the network is perfect."

This is also where networking starts to overlap with system design and distributed systems — expect the interviewer to pull at the load-balancer or caching layer once you pass the basics.

A good networking answer has five parts

When the interviewer asks "How does this request get to the server?" or "Why is this system slow?", use this structure:

1. Trace the path.
2. Name the layer where the issue probably lives.
3. State the contract that matters most: reliability, ordering, latency, or cacheability.
4. Choose the network component or protocol accordingly.
5. Name the trade-off you are accepting.

Example:

"The request path is client to DNS to TLS termination to the load balancer to the app. If users are globally distributed and the response is cacheable, I would first use a CDN because the problem is round-trip latency, not database throughput. The trade-off is freshness: cached content helps latency, but I need a clear invalidation policy."

That answer sounds much more grounded than "add more servers."

Common mistakes that cost easy points

Starting at the wrong layer

I have watched candidates spend ten minutes optimizing a database query when the real problem was that every request opened a fresh TLS connection from a distant region. Not every slow request is a database problem. Sometimes the cost is connection setup, DNS, or geography.

Treating load balancers, proxies, and CDNs as the same thing

They often work together, but they solve different problems. I ask candidates to tell me which one they would add and why — the ones who say "all three" without naming the specific bottleneck each one solves are the ones who lose this point.

Saying "UDP is faster" without the reliability contract

Speed is not the only dimension. Loss tolerance and ordering matter.

Ignoring retries

The network can fail after the server already did the work. This is the most common miss I see in system design rounds — candidates design the happy path and never mention what happens when the client retries a write.

Skipping statefulness

If sessions live in one instance, random load balancing can break behavior.

A short prep loop for networking rounds

1. Rehearse the request path out loud: DNS, connection setup, TLS, proxy or load balancer, app, cache or store.
2. Practice three trade-off prompts: TCP vs UDP, CDN vs origin-only, and retry safety for writes.
3. Map the topic to your target companies. For Cloudflare- and Vercel-shaped roles, emphasize edge, DNS, TLS, and caching. For Fortinet- and VMware-shaped roles, emphasize protocols, traffic flow, and infrastructure.

What to study next

If networking questions still feel vague, pair this guide with:

• API Design Interview Questions for retries, idempotency, and client/server contracts

The goal is not to sound like a protocol historian.

The goal is to make the interviewer trust that, when a request crosses the network, you know where time is spent, where it can fail, and what trade-off your design is actually making.