Every arrow you draw between two boxes on a system design diagram is really a phone call between two computers. Interviewers like to poke at those arrows: how does the client find the right server, how does the server push an update to the browser, why pick one protocol over another. You don't need a networking degree for this. You need to know, for each arrow, which protocol carries it and what that choice costs you.

From URL to first byte

Learn this sequence well enough to explain it out loud. Interviewers ask it directly ("what happens when you type a URL and press enter?"), and it's the foundation for questions about CDNs, load balancers, and secure connections.

DNS (Domain Name System) is the phone book of the internet: it turns a name like "mindforge.test" into a numeric address. TCP is the connection-setup handshake computers use before sending data. TLS is the layer that encrypts the connection, so nobody in between can read it.

Three facts that pay off in interviews.

DNS is a routing tool, not just a phone book. Every DNS record has a TTL (time to live), a number of seconds saying how long a client may keep using the old answer before asking again. A short TTL, say 30 to 60 seconds, lets you redirect traffic to a different server quickly if something breaks, at the cost of clients asking DNS more often. DNS can also send users to the nearest region, or shift a small percentage of traffic to a new version gradually.

Setting up a connection is expensive. It takes roughly two round trips before a single byte of your actual data moves. Picture asking a favour from someone in another country by mail: two letters have to cross the ocean before you've even started the real conversation. Over a connection with a 150 millisecond round trip, that's 300 milliseconds spent on nothing. This is why keeping connections open (called keep-alive), reusing a pool of connections, and letting a CDN handle the connection close to the user all matter so much.

Anycast is a trick where one IP address is advertised from many physical locations at once, and the network automatically routes each user to whichever location is closest. It's how CDNs and DNS providers work, and it's also how a flood of attack traffic gets spread thin across many sites instead of overwhelming one.

Remember: DNS's TTL is a dial you control, not a fixed detail. A short TTL is what lets you redirect traffic away from a dead region within a minute.

TCP vs UDP, and what QUIC changed

TCP and UDP are the two basic ways computers send data to each other over a network.

Ask yourself one question to decide between them: is a late piece of data worth more than a missing one? For a bank transfer, yes: resend it until it arrives, so use TCP. For a video call, no: a video frame that arrives 400 milliseconds late is worse than one that's simply dropped and skipped, so use UDP and hide the gap.

HTTP/3 runs on top of QUIC, and QUIC runs on top of UDP. QUIC rebuilds reliability, ordering, and congestion handling itself, instead of relying on TCP to do it. That buys two things. First, independent streams: a lost piece of data only stalls its own stream, not the whole connection. Second, connection migration: if your phone switches from Wi-Fi to mobile data mid-call, the connection survives, because it's identified by a connection ID rather than by your IP address.

Remember: TCP guarantees every byte arrives in order, so one lost piece of data stalls everything behind it. UDP drops that guarantee, which is exactly why live video prefers it.

Client-server communication styles

The single most common question interviewers ask about protocols is: "how does the client find out something changed?" There are four answers, each more powerful and more expensive than the last.

Two consequences interviewers like to push on.

WebSocket and SSE make your servers stateful. Stateful means the server remembers something between requests, in this case, which client is connected to which machine. That connection is pinned to one specific server, so you need "sticky routing" (always sending that client back to the same server), a shared messaging layer like Redis, NATS, or Kafka to deliver a message to whichever server actually holds the connection, and a careful way of closing connections gradually during a deploy. Saying "just use WebSockets" without mentioning any of that is an incomplete answer.

The number of connections becomes a real capacity number you have to plan for. One million people connected over WebSockets means one million open connections at once. If one server can comfortably hold 50,000 to 100,000 of them, that's 10 to 20 servers whose only job is holding connections open.

If you only need the server pushing to the client, prefer SSE. It's plain HTTP, it works through most existing infrastructure without special handling, it reconnects automatically, and it's roughly half the complexity of a WebSocket.

Remember: ask which direction the data needs to flow. Server-to-client only means SSE. Both sides talking means WebSocket, and WebSocket makes your servers stateful.

Service-to-service: REST, gRPC, GraphQL, and message queues

A few rules of thumb that hold up well.

Public or partner-facing calls: use REST. Anyone can call it with a basic tool like curl, caching works the normal HTTP way, and no special toolchain is required.

High-volume calls between your own internal services: use gRPC. Its binary format and the way it shares connections cut latency and CPU cost, and the generated code keeps two teams' services from drifting out of sync with each other.

Many different clients each needing different data: use GraphQL. It solves the problem of a client getting too much data or too little in one response. It costs you extra work controlling how expensive a single query can be, makes normal HTTP caching harder, and introduces the "N+1" problem, where fetching a list quietly triggers one extra database query per item; that's fixed with request batching.

The caller doesn't need the answer right now: use a queue, not a direct call. Chaining calls together multiplies your chance of failure. Five services in a row, each working 99.9% of the time, only work together about 99.5% of the time.

Remember: public and simple calls for REST. Internal and high-volume for gRPC. Many different kinds of clients for GraphQL. No need for an answer right now for a queue.

Quick recap