We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
3 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Cloud Infrastructure
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Cloud Infrastructure
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
gets all the praise. Reliable. Ordered. Error-checked. Everything arrives exactly as it was sent. It sounds like the obvious choice for everything, so why does something like UDP even exist?
Because reliability has a cost, and that cost is time.
TCP has to establish a connection (three-way handshake, add 50-100ms). It has to track sequence numbers, acknowledge every packet, and retransmit anything that gets lost. If packet #47 out of 50 goes missing, TCP holds up packets #48, #49, and #50 until #47 is retransmitted and received. This is called head-of-line blocking.
For a bank transfer, that's exactly what you want. Every byte must arrive perfectly.
For a Zoom call? If a single audio packet from 200 milliseconds ago went missing, do you really want the entire call to freeze while the system re-requests it? By the time it arrives, you've already moved on. That stale audio frame is useless. You'd rather just skip it and keep the conversation flowing.
That's UDP. No connection setup. No acknowledgments. No retransmission. No ordering guarantees. Just throw the packet at the network and hope for the best. It's reckless, and for the right use cases, it's exactly correct.
UDP. User Datagram Protocol, has one of the simplest headers in all of networking:
| Field | Size | What It Does |
|---|---|---|
| Source Port | 16 bits | Where the packet came from |
| Destination Port | 16 bits | Where it's going |
| Length | 16 bits | Total size of the UDP datagram |
| Checksum | 16 bits | Basic error detection (optional in IPv4) |
That's it. Eight bytes. Compare that to 's 20-60 byte header with sequence numbers, acknowledgment numbers, window sizes, flags, and options.
What UDP guarantees: Almost nothing. It will deliver the message to the right port on the right machine if the network cooperates. It runs a checksum to detect corrupted data (though in IPv4, even the checksum is optional).
What UDP does NOT guarantee:
Applications using UDP must handle all of these concerns themselves if they care about them. Many don't.