The Missing Piece in System Design Interviews: Networking Intuition

<Welcome to Day01/ 3-month Sprint Challenge>

Ever wonder why your beautifully designed system falls apart in an interview? Nine times out of ten, it’s because the network is a messy, unpredictable place. Today, I finally got why.

Think of it like our distributed systems are just a group of friends in different cities trying to plan a trip together. But you can only talk by mailing letters, which sometimes get lost. If you don’t get how the postal service works, or when to yell instead of write, your whole plan is built on hope. Not sense.

That’s what clicked today. So much of system design is just getting these friends to cooperate without being in the same room.

Here’s how it maps out:

First, everyone needs an address. IP addresses are like their home addresses. Without that, your letter goes nowhere.

Now, how do you communicate?

1. TCP is like sending registered mail. You get a receipt. They confirm they got it. If it gets lost, you send it again. Slow and steady, but totally reliable.

2. UDP is like shouting out the window. Fast, no waiting around. But no guarantee they heard you. Great for a quick “I’m outside!” but not for reading out a full recipe.

3. That new thing, QUIC? It’s like shouting, but with a hidden walkie-talkie inside. Still fast, but now you know if the message made it to the receiver.

Then there’s the application layer, the actual conversation.

1. HTTP is like sending formal letters back and forth. HTTPS is those letters, but locked in a little safe.

2. REST is a really common letter format that everyone knows.

3. GraphQL is like sending a checklist: “Just tell me these three things, nothing else.”

4. Need to talk in real time, like a live chat or a video call? That’s WebSockets and WebRTC more like a phone call once the connection opens.

Okay, so you’ve got your friends, addresses, and ways to talk. Now, scale it up.

Enter the organizer, the load balancer. That’s the friend who decides, “Okay, Irfan calls the hotel, Huzaifa books the rental car, and I’ll get the flights.” They spread the work so no one gets overwhelmed. And they’re constantly checking in: “Hey Huzaifa, you still alive over there?” so they don’t give tasks to someone who’s passed out.

Here’s the kicker: latency. That’s just the time it takes your letter to arrive. A letter across town gets there faster than a letter across the country. It’s not a flaw, it’s physics. That’s why for global apps, you put things closer to people, like having a friend in each city mail the flyers locally instead of from one central spot. That’s what CDNs and regional servers do.

And finally, you have to plan for failure. Because letters will get lost, and friends will fall asleep.

1. Timeouts are you saying, “If I don’t hear back in 10 minutes, I’m moving on.”

2. Retries are sending the letter again. But this only works if the action is idempotent, meaning “booking one ticket” twice doesn’t accidentally book two. You only retry safe stuff.

3. The circuit breaker is my favorite. It’s like: “Mark isn’t picking up his phone. Let’s stop calling him for an hour, let him recover, and try again gently later.”

All of this isn’t about memorizing tech specs. It’s about looking at a box-and-arrow diagram and feeling it, knowing where the mail gets slow, where a shout might be better than a letter, and when to stop calling Huzaifa.

It turns a shaky interview answer into a story that makes sense. You’re not just drawing; you’re architecting for a world where the postal service loses packages, and people shout over each other.

That’s the brick I laid today in this 3-month sprint.

See you tomorrow on Day02

Take Care.