TCP vs UDP: System Design Trade-offs

Side by side

Dimension	TCP	UDP
Data model	Byte stream; application defines message boundaries	Datagrams; message boundaries preserved
Delivery	Acknowledgments and retransmission while connection remains viable	No built-in acknowledgment or retransmission
Ordering	Ordered bytes; loss blocks later bytes	Datagrams may arrive out of order or not at all
Connection setup	Transport handshake before normal data exchange	No transport handshake; higher protocols may add one
Flow and congestion control	Built in	Must be supplied by the application or higher protocol
Transport header	At least 20 bytes	8 bytes
Security	No built-in encryption; commonly paired with TLS	No built-in encryption; use DTLS or a secure higher protocol
Operational support	Broad proxy, firewall, and load-balancer support	UDP support, mapping timeouts, and fallback need checking
Common uses	HTTP/1.1, HTTP/2, database connections	Real-time media, many DNS queries, QUIC transport

The differences that matter

TCP reliability is about bytes, not business operations. A successful write does not prove that the remote application processed or persisted a request. Payments, messages, and commands still need application acknowledgments, durable state, and idempotency across retries.

TCP delivers bytes in order, so a missing segment delays delivery of later bytes on that connection until recovery. UDP lets an application process a newer datagram without waiting for an older one. That helps with deadline-sensitive media or replaceable position updates, but the application must identify stale, duplicate, and out-of-order data.

UDP is not automatically faster. TCP connection reuse amortizes setup, and both transports face propagation delay, bandwidth limits, and congestion. With UDP, specify pacing, congestion control, bounded queues, and a loss policy rather than assuming that sending without waiting creates capacity.

Transport choice does not fully determine application semantics. QUIC runs over UDP but supplies encryption, congestion control, and reliable streams. HTTP/3 uses QUIC, so video delivered through HTTP/3 is not simply unreliable UDP delivery; loss on one QUIC stream need not block delivery on another.

Deployment can decide the choice. Ordinary browser JavaScript cannot open arbitrary TCP or UDP sockets: WebSocket provides reliable messaging over TCP, while WebTransport can expose streams and datagrams over HTTP/3 where supported. UDP designs also need path-MTU awareness, avoidance of IP fragmentation, suitable load balancing, and a plan for networks that block UDP.

Choose TCP when

You are building request-response APIs, database access, or service communication where complete data is needed and existing TCP-based libraries meet the requirements.
You need reliable chat messages or document edits, while handling persistence, reconnect replay, and deduplication at the application layer.
You are transferring files or serving buffered video through established HTTP infrastructure rather than designing a custom transport.
Broad client and network compatibility matters more than selectively dropping stale updates.

Choose UDP when

You are carrying interactive audio or video where a packet arriving after its playback deadline has little value.
You are sending replaceable state updates, such as cursor positions, and can tolerate gaps while rejecting older sequence numbers.
You need unreliable datagrams alongside reliable control traffic through a suitable protocol such as WebTransport over HTTP/3.
You are using an established UDP-based protocol, such as QUIC, rather than implementing reliability, security, and congestion control from scratch.

A worked example

Reliable edits and replaceable cursor updates

Suppose a collaborative editor has 10,000 connected users, each publishing five cursor updates per second: 50,000 incoming updates per second before fan-out. The product allows intermediate cursor positions to be dropped, but every document edit must survive reconnects. Use reliable messaging for edits, with durable acknowledgments and replay. Cursor positions can use WebTransport datagrams where supported, carrying a user identifier and increasing sequence number so receivers discard older positions. Keep only the newest pending cursor update per user. If UDP is blocked, fall back to WebSocket and coalesce updates before sending; already queued TCP bytes cannot simply be skipped.

In the interview

Start with data semantics: must every update arrive, or does the latest value replace previous values? Give separate answers for durable events and ephemeral state.
State a latency or freshness budget, then explain whether retransmitting old data helps or hurts. Expect questions about loss, jitter, reordering, and bounded buffering.
Separate transport acknowledgments from application success. Explain what happens when a connection drops after the server commits a request but before the client receives its response.
If you choose UDP, name the protocol and its congestion-control, authentication, sequencing, and recovery mechanisms. Expect probes about amplification attacks, NAT mappings, and blocked UDP.
Clarify client constraints and alternatives. For browser applications, discuss WebSocket, WebRTC, or WebTransport rather than proposing a raw UDP socket.

Common mistakes

Claiming TCP guarantees exactly-once processing or durable delivery. Its guarantees do not extend to application commits or retries across connections.
Claiming UDP is always lower latency or higher throughput without considering loss, congestion control, connection reuse, and protocol implementation.
Choosing UDP for all video traffic. Buffered streaming usually needs complete segments, while interactive media has different deadline and loss requirements.
Treating UDP-based protocols as inherently unreliable. QUIC supplies reliable streams, and applications can combine reliable control messages with lossy updates.

Where it comes up

Interview questions where choosing between TCP and UDP comes up.

Questions people ask

Is UDP faster than TCP?

UDP has a smaller transport header and no transport-level connection handshake, but that does not guarantee better application latency or throughput. Results depend on connection reuse, network loss, congestion, payload sizes, and the protocol built above UDP. UDP is useful when avoiding recovery of stale data matters.

Does TCP guarantee delivery?

TCP retransmits lost data and presents an ordered byte stream, but a connection can still fail before all data arrives. TCP also does not prove that the receiving application processed or persisted the data. Use application acknowledgments and retry-safe operations when those guarantees matter.

Does HTTP use TCP or UDP?

HTTP/1.1 and HTTP/2 normally use TCP, with TLS for HTTPS. HTTP/3 uses QUIC over UDP. QUIC supplies reliable streams, encryption, and congestion control, so HTTP/3 does not leave HTTP messages subject to unrecovered UDP loss.