TCP vs. UDP: Choosing the Right Protocol for System Design

Hello again. In the previous lesson, you established how an IP address gets traffic to a network destination, how a port selects a service on that destination, and how the protocol plus source and destination addresses distinguish simultaneous conversations. This lesson builds directly on that model: TCP and UDP use the same addressing idea, but offer applications very different transport contracts.

For entry-level system-design interviews, do not frame the choice as simply “TCP is good, UDP is fast.” Instead, identify what the application needs: exact delivery, ordering, connection state, low delay, tolerance for loss, and the cost of implementing missing behavior yourself.

---

Two transport contracts for the same endpoints

Both TCP and UDP operate at the transport layer. They use source and destination ports, so both can carry traffic between endpoints such as:

Client: 203.0.113.10:52134
Server: 198.51.100.20:443

The protocol is part of the endpoint identity. Thus, TCP port 443 and UDP port 443 are separate: a host can receive TCP and UDP traffic on the same port number.

The core distinction is the service each protocol gives the application:

Property	TCP	UDP
Communication model	Connection-oriented	Connectionless
Unit delivered to app	Ordered byte stream	Individual datagrams
Delivery acknowledgement	Yes	No built-in acknowledgement
Retransmission after loss	Yes, while connection remains viable	No built-in retransmission
Ordering	Preserves byte order	No built-in ordering
Flow and congestion control	Built in	Not provided by UDP itself
Header size	At least 20 bytes, plus options where used	8 bytes
State at endpoints	Connection state maintained	Little transport-level state

The visual below captures the broad intuition: TCP creates an ongoing relationship between two endpoints, while UDP lets a sender transmit independent datagrams.

One correction to the image’s wording is worth making now: UDP is not automatically “faster” in the sense that its packets travel through the Internet more quickly. Network propagation and routing delay are largely the same. UDP has less transport overhead and skips TCP’s setup and recovery behavior, which can produce lower application-visible delay when loss is acceptable.

Watch this compact overview before going into the system-design consequences.

---

TCP: an ordered, reliable byte stream

When an application opens a TCP connection, the two endpoints first perform a three-way handshake. The handshake establishes connection state at both ends and confirms that each side can communicate with the other before normal data transfer begins.

Afterward, TCP presents the application with a stream of bytes in order. If an application writes:

create-order: 7812

TCP may split those bytes across several IP packets. The receiver may receive those packets out of order, or one may be lost. TCP handles those details below the application:

1. It labels transmitted data with sequence numbers.
2. The receiver acknowledges received data.
3. The sender retransmits data it believes was lost.
4. The receiver reassembles data into the original byte order before giving it to the application.

This is why TCP is appropriate when missing or reordered data would change the meaning of an operation. A database query, a file download, an API request to create an order, and an email transfer all need the complete data in the intended order.

TCP is a byte stream, not a message queue

This distinction matters in backend code. TCP does not preserve your application’s request boundaries.

Suppose a client performs two writes:

write 1: "HELLO"
write 2: "WORLD"

The server might read:

"HELLOWORLD"

in one read, or:

"HEL"

followed by:

"LOWORLD"

in two reads. TCP guarantees the eventual order of bytes, not that one write becomes one read.

Protocols built on TCP therefore define their own message framing. HTTP, for example, uses headers such as Content-Length or chunked transfer encoding to make request and response boundaries clear. You will examine HTTP’s structure in the next lesson.

The costs of TCP’s useful features

TCP’s reliability is not free:

• Connection setup: The initial handshake adds a round trip before application data can be exchanged. Applications often reuse established connections to amortize this cost.
• Endpoint state: Both client and server maintain state for each active connection. At a large scale, many idle or maliciously created connections consume memory, file descriptors, and other resources.
• Retransmission delay: When a segment is missing, TCP waits for it or retransmits it before delivering later bytes to the application.
• Head-of-line blocking within a TCP stream: If bytes earlier in one TCP connection are lost, later bytes on that same connection wait, even if they have already arrived.
• Rate adaptation: TCP applies flow control to avoid overwhelming the receiver and congestion control to reduce network overload. This protects the network and tends to use available capacity effectively, but it can reduce the sending rate when congestion is detected.

These costs are usually worthwhile for business operations where correctness matters more than a few milliseconds of delay.

Be precise about the word reliable. TCP makes delivery failures visible and attempts recovery; it cannot make an unavailable server or broken network path work. If the connection fails after a server receives a request but before the client receives the response, the client may not know whether the business operation completed. Later in the course, idempotency keys will address precisely that distributed-systems problem.

---

UDP: independent datagrams with no built-in recovery

UDP sends datagrams independently. There is no TCP-style handshake and no maintained transport connection state. A sender can place a UDP datagram on the network immediately.

A UDP receiver gets a discrete datagram rather than an arbitrary slice of a byte stream. If the sender transmits one datagram containing a player’s current position, the receiving application either receives that datagram as one unit or does not receive it. UDP does not split its delivered payload across multiple receives in the way TCP’s byte stream can be read in pieces.

However, UDP itself does not provide:

• confirmation that a datagram arrived,
• retransmission when one is lost,
• ordering when datagrams arrive out of order,
• duplicate suppression,
• flow control or congestion control comparable to TCP’s.

An application using UDP must decide which, if any, of these behaviors it needs. It may add sequence numbers, acknowledgements, retransmissions, rate limits, or encryption at a higher layer. That flexibility is useful, but it transfers design and implementation responsibility from the transport protocol to the application protocol.

The following reading gives a concise initial comparison and connects UDP’s trade-off to familiar workloads. Treat its “faster” wording as shorthand for avoiding connection setup and reliability overhead, not as a claim that a UDP packet physically travels faster across the same route.

Why loss can be preferable to delay

Consider a voice call. At time $t$, a microphone creates a small audio frame. If that frame is lost, retransmitting it later may take longer than the frame remains useful. By the time it arrives, the conversation has moved on.

The receiver can instead play the next frame, perhaps filling the gap with a small amount of smoothing or silence. The listener may hear a brief artifact, but the conversation remains current.

The same reasoning often applies to:

• a video-conference frame that is immediately replaced by a newer frame;
• a player’s frequently updated position in an online game;
• a live sensor reading when the newest reading is more valuable than a delayed old reading;
• a periodic metric where losing one measurement does not invalidate the overall trend.

In these cases, the application values freshness over perfect historical completeness.

UDP does not mean “loss is good.” It means the application is permitted to decide that some loss is acceptable, and avoids paying for generic recovery behavior when the lost data would already be obsolete.

---

Choosing a protocol in a system design

The protocol follows the product requirement, not the other way around. A useful design habit is to classify a data item by what happens if it is lost, duplicated, reordered, or delayed.

Workload or data	Usual transport choice	Why
Login, payments, order creation, account updates	TCP-based application protocol	Missing or reordered bytes can corrupt the operation; application needs reliable request delivery.
Browser API calls and conventional web pages	TCP for HTTP/1.1 and HTTP/2	HTTP historically uses TCP’s ordered byte stream and reliable transfer.
HTTP/3 web traffic	UDP underneath QUIC	QUIC uses UDP as a substrate but implements reliable streams, congestion control, and encryption above it. UDP alone is not why HTTP/3 is reliable.
Database connections	TCP	Queries and results require complete, ordered transfer.
File transfer and email	TCP	Every part of the content matters; retries are preferable to silently incomplete data.
Interactive voice and video	Often UDP-based real-time protocols	Late data is often worse than lost data; applications can adapt to limited loss.
Real-time game state	Often UDP, with application-level reliability for selected events	New state supersedes old state, while critical actions can receive their own acknowledgement logic.
DNS lookup	Traditionally UDP for ordinary small queries	Avoids a connection handshake for a short request and response. DNS can use TCP when needed, such as for large responses or other specific operations.
Best-effort metrics	Sometimes UDP	A system may accept losing an occasional metric to keep collection lightweight.
Audit logs and billing events	TCP or a durable messaging path	Losing an event creates a correctness, compliance, or financial problem.

Two conclusions from this table are especially important.

First, the application protocol matters more than the raw TCP/UDP label. HTTPS commonly uses TCP today in HTTP/1.1 and HTTP/2 deployments, but HTTP/3 uses QUIC over UDP. QUIC adds back many capabilities people associate with TCP, including reliable streams and congestion control. The choice was made so the web protocol could control its behavior more flexibly, not because ordinary UDP suddenly provides reliability.

Second, systems frequently use both protocols in different paths. A multiplayer game might use a reliable TCP-based API for authentication, purchases, and match setup, while using UDP for frequent in-game position updates. The system has different correctness requirements in those two flows.

---

Avoid the common interview shortcuts

A concise answer can still be technically sound if it avoids four common mistakes.

“UDP is faster than TCP”

A better statement is: UDP has less transport overhead and no connection setup; it may reduce application-visible delay when waiting for reliable, ordered delivery would be harmful.

For a single packet traveling over the same network path, UDP does not give it a magical speed advantage. Under loss, a UDP application that must implement acknowledgements and retries might even become more complex and no faster in practice.

“TCP guarantees that the business operation happens once”

TCP provides reliable, ordered transport of bytes while the connection remains healthy. It does not guarantee that a server processed an API request exactly once or that the client received the response.

For example, a server could process a POST /orders request, then lose its network connection before returning the response. The client may retry because it cannot tell what happened. Preventing duplicate order creation requires application-level techniques, not TCP alone.

“TCP is secure, UDP is insecure”

Neither TCP nor UDP encrypts application data by itself. TLS protects common TCP-based HTTPS traffic; protocols using UDP can use security mechanisms such as DTLS or QUIC’s built-in use of TLS. Security is a separate requirement from reliable delivery.

“UDP is always best for streaming”

Interactive real-time media often uses UDP because timeliness dominates. But many video services distribute on-demand video or even live broadcasts through HTTP over TCP-based connections because reliability, infrastructure compatibility, and adaptive buffering are valuable. “Streaming” by itself is not enough information to select a protocol.

---

A practical decision rule

When explaining a protocol choice in an interview, state the workload requirement first and then the trade-off:

This path carries a payment request, so every byte must arrive in order and a lost request must be detected. I would use an HTTP API over TCP, then add application-level idempotency because TCP alone cannot prevent duplicate business operations after a timeout.

Contrast that with:

This path carries live player-position updates several times per second. A delayed old position is not useful, so I would favor UDP or a real-time protocol built on it. The client can use sequence numbers to discard stale updates, while critical game events receive explicit application-level acknowledgement.

That explanation demonstrates the main system-design skill: selecting a mechanism because it satisfies a requirement while acknowledging its failure modes.

---

Key takeaways

• TCP and UDP both use IP addresses and ports to deliver data to processes, but they expose different contracts to applications.
• TCP provides a connection-oriented, reliable, ordered byte stream with acknowledgements, retransmission, flow control, and congestion control.
• UDP provides independent datagrams without built-in delivery confirmation, retransmission, ordering, or congestion control.
• TCP is generally the default for APIs, databases, file transfer, email, and operations where complete, ordered data matters.
• UDP is valuable when freshness matters more than perfect delivery, especially for interactive voice, video, game-state updates, and small best-effort queries.
• TCP does not provide encryption or exactly-once business semantics; UDP is not inherently faster or inherently unsuitable for reliable systems.
• Modern protocols can build reliability above UDP, as QUIC does for HTTP/3.

Next, you will move one layer up and interpret the essential parts of an HTTP request and response. That will show how web applications turn TCP’s raw byte stream into structured operations such as GET, POST, headers, status codes, and bodies.