In our last lesson, we took a deep dive into the mechanics of the Transmission Control Protocol (TCP), focusing on how it establishes and maintains a reliable connection. You learned about the three-way handshake, data transfer with acknowledgements, and the four-way termination process. This foundational knowledge is crucial because now we can ask a classic backend engineering question: When should we use TCP, and when should we use its primary alternative?
Today, we'll address exactly that. Our goal is to compare TCP and UDP, identifying when each is appropriate for backend communication. We will explore the User Datagram Protocol (UDP), contrast its design philosophy with TCP's, and analyze the critical tradeoffs between reliability and speed. Mastering this comparison is essential for making sound architectural decisions and for answering a very common category of interview questions.
The Fundamental Tradeoff: Reliability vs. Speed
In the previous lesson, we established that TCP goes to great lengths to provide a reliable, ordered stream of data over an inherently unreliable network. It uses handshakes, sequence numbers, acknowledgements, and flow control. All these features, however, come at a cost: overhead and latency.
UDP, or User Datagram Protocol, represents the other side of this tradeoff. It prioritizes speed and simplicity by stripping away almost all of TCP's reliability features.
To get a quick intuition for this fundamental difference, a simple analogy is often helpful.
System Design Mock Interview: Understanding TCP vs UDP
The article "System Design Mock Interview: Understanding TCP vs UDP" provides a clear and memorable analogy to frame the comparison. It likens TCP to a registered mail service and UDP to sending a postcard.
Please read the section titled How I’d Explain This to a Junior Dev. As you read, think about how each part of the analogy maps to the TCP features we discussed in the last lesson (e.g., "calling your friend" is the handshake, "signing for it" is the acknowledgement).
This "Registered Mail vs. Postcard" analogy is a powerful mental model. TCP is your go-to when every single piece of data must arrive, in order, without corruption. UDP is for when you want to send information as quickly as possible, and you can tolerate some loss or disorder.
Diving into UDP: The "Fire and Forget" Protocol
UDP is a connectionless protocol. This is the key concept that underpins all its characteristics. Unlike TCP, there is no three-way handshake to establish a connection and no four-way handshake to tear it down.
A UDP sender simply formats a packet of data, called a datagram, adds a small header (containing source/destination ports, length, and an optional checksum), and sends it to the destination IP address. It doesn't know or care if the destination is ready, if it received the packet, or if the network is congested. It's a "fire and forget" approach.
Let's watch a short video that breaks down the characteristics of both protocols, starting with UDP.
TCP vs. UDP in 12 minutes | Systems Design Interview 0 to 1 With Ex-Google SWE
The video "TCP vs. UDP in 12 minutes" by Jordan has no life offers a concise, whiteboard-style explanation that's great for interview prep.
Watch the following segments to solidify your understanding: UDP Explained: First, watch the explanation of UDP from the beginning of the comparison. Note its simplicity, speed, and lack of guarantees beyond an optional checksum for data integrity. TCP Recap: Then, quickly review the section on TCP from its introduction to the end of the reliability discussion. This will serve as a good refresher and contrast to the UDP section you just watched. Use Cases: Finally, skip to the end and watch the summary of when to use each protocol.
A Side-by-Side Comparison
Now that we've established the core ideas, let's organize the comparison in a way you might present it in an interview.
This infographic provides a high-level visual summary of the key differences between TCP and UDP, including their reliability characteristics, typical applications, and supported communication patterns.
To build on this, here is a more detailed breakdown of their features:
| Feature | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
|---|---|---|
| Connection | Connection-oriented (requires 3-way handshake) | Connectionless (no handshake) |
| Reliability | High. Guarantees delivery via acknowledgements and retransmissions. | Low. No guaranteed delivery ("best effort"). |
| Ordering | Guarantees packets are delivered and reassembled in order. | No guaranteed order. Datagrams may arrive out of sequence. |
| Error Checking | Extensive, using checksums. Corrupted packets are retransmitted. | Basic, using an optional checksum. Corrupted packets are dropped. |
| Flow Control | Yes. Prevents sender from overwhelming the receiver. | No. Can lead to packet loss if sender is faster than receiver. |
| Congestion Control | Yes. Slows down transmission to avoid overloading the network. | No. Can contribute to network congestion. |
| Header Size | 20 bytes (plus options) | 8 bytes |
| Speed | Slower, due to reliability overhead. | Faster, due to minimal overhead. |
| Use Cases | Web browsing, file transfer, email, database connections. | Live streaming, online gaming, VoIP, DNS. |
To see how you might articulate these points in a dialogue, the following reading is structured as a mock interview.
System Design Mock Interview: Understanding TCP vs UDP
This article walks through the comparison in a conversational, interview-style format, which is excellent practice.
Read through the first four steps of the article: The Core Distinction: Reinforces the connection-oriented vs. connectionless nature. TCP's Reliability: Summarizes the mechanisms you learned about in the last lesson. UDP's Advantages: Explains why its "unreliability" is a feature. Common Scenarios: Sets up the discussion of specific applications.
Making the Choice: Backend Application Scenarios
The crucial skill for a backend engineer is knowing when to choose which protocol. The decision almost always boils down to this: Is it more important for the data to be perfectly correct, or for it to arrive quickly?
When to Choose TCP
Choose TCP when data integrity is non-negotiable.
- Web Browsing (HTTP/S): A web page would be garbled if HTML, CSS, or JavaScript packets were missing or out of order. All modern web traffic runs on TCP (or QUIC, which builds reliability on top of UDP, a topic for another day).
- File Transfer (FTP/SFTP): A corrupted file is a useless file. You need every single bit to be correct.
- Email (SMTP): You expect your emails to arrive complete and readable.
- Database Connections: When your application server queries a database, the commands and the resulting data must be transmitted with perfect fidelity.
When to Choose UDP
Choose UDP when low latency is critical and you can tolerate some data loss.
- Live Video/Audio Streaming (e.g., Zoom, YouTube Live): If a packet representing a single video frame is lost, it's better to just skip it and show the next frame. Waiting to retransmit the lost frame would cause the entire stream to stutter and fall behind real-time. The user might see a brief artifact, but the stream continues smoothly.
- Online Gaming: In a fast-paced game, a player's position from 100 milliseconds ago is irrelevant. You need the most current position now. Sending updates via UDP ensures they arrive with minimum delay. The game's code can smooth over (interpolate) any dropped packets.
- Voice over IP (VoIP): Similar to video, a dropped audio packet might cause a tiny blip, but retransmitting it would introduce noticeable, jarring delays in the conversation.
- DNS (Domain Name System): A DNS query is a small, single request ("What's the IP for
google.com?") followed by a small, single response. It's faster to use UDP. If the response is lost, the client can simply time out and ask again. The overhead of a TCP handshake for such a simple transaction is unnecessary.
Let's hear a practical discussion on these tradeoffs from a backend perspective.
When to use UDP vs TCP in Building a Backend Application?
In this video, Hussein Nasser discusses the choice between TCP and UDP in the context of building specific applications like chat and multiplayer games.
Please watch these two key sections: Chat Applications: Listen to his analysis of why TCP (or protocols built on it, like WebSockets) is generally a good fit for chat, where message integrity is important and the latency from acknowledgements is acceptable. Gaming Applications: Contrast this with his discussion on gaming, where the demands of low latency often push developers toward UDP, even if it means they have to build some reliability logic themselves at the application layer.
Hussein's analysis highlights a key point: you can build reliability on top of UDP yourself, but it's complex. For most use cases, it's better to rely on TCP's battle-tested implementation unless you have a very specific, latency-sensitive requirement that justifies the extra engineering effort.
Key Takeaways
- TCP is connection-oriented, reliable, and ordered. It's like sending registered mail. It guarantees delivery at the cost of higher latency and overhead.
- UDP is connectionless, unreliable, and unordered. It's like sending a postcard. It offers high speed and low overhead by forgoing any guarantees.
- The choice between them is a fundamental tradeoff between reliability and speed.
- Choose TCP for applications where data integrity is paramount (web, files, email).
- Choose UDP for real-time applications where low latency is critical and some data loss is acceptable (streaming, gaming, VoIP, DNS).
Being able to clearly articulate these differences and provide relevant examples is a strong signal in a backend interview that you understand how network protocols impact application architecture and performance.
In our next lesson, we will explore one of the most common UDP-based services in detail: the Domain Name System (DNS). We'll trace the step-by-step process of how a domain name is resolved into an IP address, a critical first step in almost every network request.