TCP vs UDP — How to Pick
TL;DR
Use TCP for everything unless you have a specific reason to use UDP. That reason is almost always "real-time data where a dropped packet is better than a late one."
The Decision Flowchart Is Short
Here's the honest truth: this decision is usually easy.
Question 1: Does your data need to arrive completely and in order? - Yes → TCP - No → Maybe UDP. Keep reading.
Question 2: Is latency more important than completeness? Would you rather skip missing data than wait for it? - Yes → UDP is worth considering - No → TCP
Question 3: Are you building for web browsers? - Yes, and not doing video calls → TCP (browsers can't do raw UDP) - No, or you're doing video → UDP might work
That's about it. For 95% of system design scenarios, TCP wins by default.
Side by Side
| UDP | TCP | |
|---|---|---|
| Connection | None. Just send data. | Must set up a connection first (handshake). |
| Reliability | Packets can vanish. Nobody tells you. | Every packet is guaranteed to arrive. |
| Ordering | Packets can arrive in any order. | Packets are always delivered in order. |
| Speed | Faster. Less overhead. | Slower. Handshakes + acknowledgments. |
| Header size | 8 bytes | 20-60 bytes |
| Analogy | Walkie-talkie. Shout and hope. | Phone call. Set up, talk, hang up. |
| Good for | Streaming, gaming, VoIP | Everything else |
When to Reach for UDP
There are really only a few scenarios:
Real-time audio/video — A dropped video frame is invisible. A frozen video is unbearable. Zoom, Google Meet, Discord voice — they all use UDP (via WebRTC) for the media streams.
Online gaming — Player position updates come 30-60 times per second. If one gets lost, the next one arrives in 16 milliseconds anyway. Why waste time retransmitting?
High-volume telemetry — If you're sending thousands of log entries or sensor readings per second, losing a few is usually acceptable. The overhead of maintaining TCP connections for each data source might not be worth it.
DNS — Tiny queries, tiny responses. If a DNS lookup packet gets lost, the client just sends another one. Faster than setting up a TCP connection for a 50-byte question.
When to Stick With TCP
Everything else. Seriously.
- Loading a webpage → TCP
- Calling a REST API → TCP
- Querying a database → TCP
- Sending an email → TCP
- Uploading a file → TCP
- Processing a payment → Definitely TCP (you don't want payment data getting lost!)
If losing a single packet would break your result or corrupt your data, that's TCP. No question.
Real Systems Use Both
Here's something that often surprises beginners: a single application can use both protocols at the same time.
Take a video conferencing app like Zoom:
- The login flow, chat messages, and meeting metadata use TCP (via HTTPS). You can't afford to lose a login request or a chat message.
- The actual video and audio streams use UDP (via WebRTC). A dropped frame is better than a frozen feed.
A multiplayer game might work the same way:
- TCP for the lobby, inventory, chat
- UDP for real-time player positions and actions
Mentioning this kind of hybrid approach shows you understand why each protocol exists, not just what they do.
The Summary
Is it real-time media or gaming?
├── Yes → UDP (probably via WebRTC for browsers)
└── No → TCP (the default for everything else)
Don't overthink it. Start with TCP. Only switch to UDP if you can clearly explain why a lost packet is acceptable (or even preferable) in your specific scenario.
Interview Tip
Default to TCP and don't mention it — it's assumed. Only bring up UDP if the problem clearly involves real-time data. If you do, explain what happens when packets get lost: "We use UDP for the video stream because a dropped frame is better than a frozen feed — the client just moves on." That kind of reasoning is what interviewers want to hear.