UDP: Fast, Honest, and Unreliable

If you are following this series then by now, we’ve seen two important things.

First, the network is unreliable by default.
Second, TCP exists to manage that unreliability and make it usable.

So naturally, a question pops up. “If TCP already solves reliability, why does UDP even exist?”

At first glance, UDP looks like a mistake. No guarantees. No retries. No ordering. No connection.

Why would anyone choose that?

The answer is simple and slightly uncomfortable. Because sometimes reliability is the wrong goal.

Let’s Start With a Bad Assumption

Many people unconsciously assume this: “More reliability is always better.” That sounds reasonable. It’s also wrong. Reliability comes with a cost:

• Extra coordination

• Extra waiting

• Extra overhead

In some situations, that cost is worse than losing data. UDP exists for those situations.

What UDP Actually Is

UDP doesn’t try to manage the network. It doesn’t pretend the chaos isn’t there. It doesn’t smooth things over. It says:

“Here’s a message.
Do your best.
I’m not waiting.”

That’s not laziness. That’s honesty.

No Connection, No Conversation

With UDP:

• There is no handshake

• No agreement that someone is listening

• No shared state

You send data. It might arrive. It might not. UDP doesn’t follow up. It doesn’t ask questions. It moves on.

Why This Can Be a Feature

Think about a live video call or a competitive game like Valorant or Counter-Strike.

If you are in a gunfight in a game and a packet of data (representing your movement) gets lost, you don't want the game to "pause" for 200ms while TCP tries to re-send that old packet. By the time that old packet arrives, you’re already dead.

In real-time systems, old data is worse than no data. UDP chooses speed over perfection. It skips the "Handshake" we talked about in the TCP article. There is no SYN, SYN-ACK, or ACK. It just starts blasting data.

Speed Comes From Not Waiting

TCP waits:

• For acknowledgements

• For missing pieces

• For the right order

UDP waits for nothing. That makes it:

• Faster

• Lower latency

• Predictable in timing

Not reliable in delivery. But reliable in behavior. That distinction matters.

UDP Is Lightweight (Stateless), and That’s Powerful

To understand why UDP is so fast, we have to look at its "overhead."

• TCP Header: Usually 20 bytes. It’s packed with sequence numbers, acknowledgment numbers, and window sizes to track everything.

• UDP Header: Only 8 bytes. It contains the Source Port, Destination Port, Length, and a Checksum. That’s it.

Because the header is so small, there’s less "extra" data to process and send. It’s the difference between moving house with 20 packed suitcases (TCP) versus running out the door with just your phone and keys (UDP).

Real Systems That Prefer UDP

In backend architecture, you’ll encounter UDP in specific but crucial places:

1. DNS (Domain Name System): When your browser needs to turn google.com into an IP, it uses UDP. It’s a quick "Hey, what’s the IP?" "Here it is." Done. If it fails, the browser just tries again. No need for a formal connection.

2. Streaming & VoIP: Netflix (for the actual video stream) and Zoom use UDP-based protocols. A dropped frame of video is a tiny glitch; a 2-second pause to "recover" that frame is a bad user experience.

3. IoT Devices: Small sensors with tiny batteries often use UDP because it requires less power and processing to send a quick burst of data.

4. Modern protocols like HTTP/3 (yes, really)

In all these cases, timeliness matters more than perfection.

“But What If I Need Reliability?”

Here’s the important part. Using UDP doesn’t mean giving up on reliability forever. It means: “I want control over how reliability is handled.” Many systems build their own reliability on top of UDP:

• Custom retries

• Application-level ordering

• Domain-specific logic

Why?

Because they can do it better for their use case than TCP’s general-purpose approach.

UDP vs TCP Is Not a Battle

This isn’t:

• Old vs new

• Bad vs good

• Simple vs advanced

It’s about intent.

TCP says: “I will make delivery safe, even if it takes time.”

UDP says: “I will deliver fast, even if it’s imperfect.”

Neither is wrong. Each is honest about its tradeoffs.

Why Backend Engineers Should Care

If you think UDP is “unsafe TCP”, you’ll misuse it. If you understand UDP:

• You design better real-time systems

• You understand why some things feel instantaneous

• You stop forcing TCP where it doesn’t belong

Good backend engineering is about choosing the right failure mode.

A Quiet Pattern Emerging

Let’s zoom out for a moment.

• Raw networks are unreliable

• TCP manages unreliability

• UDP accepts unreliability

Different layers. Different philosophies. Now there’s one final piece left.

What Comes Next

So far, we’ve talked about how data moves and how it’s delivered.

The next question is inevitable: “How do applications actually use this to talk to each other?”

That’s where HTTP enters the picture.

➡️ Next article:
Why HTTP Had to Be Stateless

This article is part of the Thinking in Backend series, where we learn backend engineering by focusing on how systems think, not just how code runs.