Bird
Raised Fist0

TCP vs UDP - When Reliability Matters and When Speed Wins

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
TCP vs UDP - When Reliability Matters and When Speed Wins
Designing systems that choose between TCP and UDP based on reliability and latency needs
mediumNetworking and ProtocolsFreq: common
⚙️
Functional Requirements
  • Support reliable, ordered message delivery for critical data flows (e.g., financial transactions).
  • Support low-latency, unordered message delivery for real-time streaming or gaming.
  • Allow dynamic selection between TCP and UDP protocols based on message type or priority.
  • Provide mechanisms for retransmission and congestion control when reliability is required.
  • Enable detection and handling of packet loss or corruption in unreliable channels.
  • Support multiplexing multiple logical streams over the same transport connection.
📊
Non-Functional Requirements
  • System must handle up to 2 billion daily active users (DAU).
  • End-to-end latency for UDP-based real-time messages must be under 50ms P99.
  • TCP-based reliable messages must achieve 99.99% delivery success within 200ms.
  • Network bandwidth usage should be optimized to avoid exceeding 100 Gbps peak outbound traffic.
  • System uptime must be 99.999% to ensure continuous availability.
❓
Clarifying Questions to Ask
  • What types of messages require reliability vs low latency?
  • What is the expected message size and frequency per user?
  • Are there any constraints on network environments (e.g., mobile, WiFi, wired)?
  • Is packet ordering required for UDP messages or only for TCP?
  • How should the system handle network congestion or packet loss?
  • Are retransmissions allowed for UDP or only for TCP?
Out of Scope
✗ Designing the entire application layer protocol beyond transport choice.
✗ Handling encryption or authentication mechanisms (e.g., TLS).
✗ Physical network infrastructure design (e.g., fiber optics, switches).
✗ Detailed OS kernel TCP/IP stack implementation.
📌
Assumptions
  • 2 billion DAU
  • 40 messages per user per day
  • 100 bytes average message size
  • Peak traffic concentrated in 4 hours daily (peak factor 6)
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 msg/sec
peak write qps925,926 × 6 ≈ 5,555,556 msg/sec
read qpsAssuming 3 reads per write: 925,926 × 3 ≈ 2,777,778 msg/sec
💾
Storage Estimate
daily storage bytes2B × 40 × 100 = 8,000,000,000,000 bytes ≈ 7.28 TB/day
retention days7
total storage bytes7.28 TB × 7 = 50.96 TB
with replication 3x50.96 TB × 3 = 152.88 TB
🖥️
Server Estimate
tcp connection serversAssuming 100K concurrent TCP connections, each server handles 10K connections → 10 servers
udp processing serversTo handle 5.5M peak UDP messages/sec, with each server processing 500K msg/sec → 11 servers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          | Client Devices |
          +--------+-------+
                   | TCP/UDP
                   v
          +--------+--------+
          | Protocol Router |
          +--------+--------+
           /                 \
          /                   \
 +-------+-------+     +------+-------+
 | TCP Handler   |     | UDP Handler  |
 +-------+-------+     +------+-------+
         |                      |
         v                      v
 +-------+-------+     +--------+-------+
 | Reliable Msg  |     | Real-time Msg  |
 | Processing    |     | Processing     |
 +-------+-------+     +--------+-------+
         |                      |
         v                      v
 +-------+-------+     +--------+-------+
 | Storage Layer |     | Analytics Layer|
 +---------------+     +----------------+
🧩
Components
Protocol Router
Routes incoming messages to TCP or UDP handlers based on message metadata
Why thisCentralizes protocol decision logic to optimize resource allocation and monitoring
Why notClient-side protocol selection offloads complexity but reduces centralized control and monitoring
TCP Handler
Manages TCP connections, ensuring reliable, ordered delivery with retransmissions
Why thisLinux kernel TCP stack provides mature congestion control and reliability guarantees
Why notCustom TCP implementations lack robustness and require extensive testing
UDP Handler
Processes UDP packets with minimal overhead for low-latency delivery
Why thisUDP allows sending packets without handshake or retransmission, minimizing latency
Why notTCP for all traffic adds latency due to connection setup and retransmission overhead
Reliable Message Processing
Implements application-level logic for message ordering, deduplication, and persistence
Why thisEnsures end-to-end reliability beyond transport layer, critical for financial or transactional data
Why notRelying solely on TCP ignores application-level consistency and idempotency requirements
Real-time Message Processing
Handles best-effort delivery of time-sensitive data like live video or gaming events
Why thisPrioritizes speed over reliability, dropping late or lost packets to maintain freshness
Why notUsing TCP here causes unacceptable latency spikes due to retransmissions
Storage Layer
Persists reliable messages with replication and indexing for fast retrieval
Why thisApache Cassandra supports high write throughput and linear scalability for 7+ TB/day
Why notRelational DBs like PostgreSQL require complex sharding and do not scale linearly at 5M writes/sec
Analytics Layer
Processes real-time UDP message streams for monitoring and metrics
Why thisApache Flink supports low-latency stream processing with exactly-once semantics
Why notBatch processing systems like Hadoop introduce unacceptable delays
🔄
Data Flow
1
Client Devices → Protocol Router
Send message with metadata indicating reliability requirement
Client tags messages as TCP or UDP based on use case
2
Protocol Router → TCP Handler or UDP Handler
Route message to appropriate protocol handler
Centralized routing enables monitoring and dynamic load balancing
3
TCP Handler → Reliable Message Processing
Ensure ordered, reliable delivery with retransmissions
Uses kernel TCP stack and application-level deduplication
4
UDP Handler → Real-time Message Processing
Process best-effort messages with minimal delay
Drops late or lost packets to maintain low latency
5
Reliable Message Processing → Storage Layer
Persist messages with replication and indexing
Supports queries and recovery in case of failures
6
Real-time Message Processing → Analytics Layer
Stream messages for monitoring and metrics
Enables operational visibility and SLA enforcement

Practice

(1/5)
1. In a fraud detection system ingesting thousands of transactions per second, which component is best suited to decouple the high-throughput transaction ingestion from downstream real-time scoring to avoid backpressure?
easy
A. Use a relational database with batch inserts to buffer transactions
B. Use direct synchronous HTTP calls from ingestion to scoring service
C. Use an in-memory cache like Redis to store incoming transactions temporarily
D. Use a distributed message queue like Kafka with partitioning by user ID

Solution

  1. Step 1: Identify decoupling mechanism

    Relational DB batch inserts (A) add latency and don't handle high write throughput well. Redis (C) lacks durability guarantees for buffering. Direct synchronous calls (D) cause backpressure and tight coupling.

  2. Step 2: Evaluate Kafka suitability

    Kafka supports high-throughput, partitioned by user ID to maintain ordering per user, and durable storage, enabling asynchronous processing and backpressure handling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka partitions decouple ingestion and scoring with durability and ordering [check]
Hint: Kafka partitions buffer high-throughput streams reliably [check]
Common Mistakes:
2. In a system trace, at Step 3 the Storage Estimator component calculates daily storage needs. If the average object size is 2MB and the system expects 500K new objects daily, what is the storage estimate at Step 3?
easy
A. Cannot estimate without knowing retention period
B. 1TB per day, calculated as 500K objects x 2MB each
C. 2TB per day, assuming 4MB average object size instead
D. 500GB per day, assuming 1MB average object size instead

Solution

  1. Step 1: Calculate daily storage

    Multiply 500,000 objects by 2MB each = 1,000,000 MB = 1TB per day.

  2. Step 2: Eliminate other options

    500GB per day, assuming 1MB average object size instead uses wrong object size; 2TB per day, assuming 4MB average object size instead doubles size incorrectly; Cannot estimate without knowing retention period ignores that retention affects total storage, not daily estimate.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    500K x 2MB = 1TB daily storage [check]
Hint: Daily storage = object count x average size [check]
Common Mistakes:
3. If the recursive DNS server's cache is completely disabled, what is the most immediate failure mode experienced by users during domain resolution?
medium
A. Users' browsers fallback to using IP addresses directly, bypassing DNS
B. Users receive stale IP addresses causing connection failures
C. The recursive server returns IP addresses from its local hosts file instead of querying DNS servers
D. The recursive server blocks user queries until authoritative servers respond, increasing latency and potential timeouts

Solution

  1. Step 1: Understand recursive server caching role

    The recursive DNS server cache reduces query latency by storing recent results. Without caching, every query requires a full resolution chain traversal.

  2. Step 2: Trace failure impact

    Without cache, recursive server must synchronously query authoritative servers for every request, causing increased latency and possible timeouts, blocking user queries.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No cache -> synchronous queries -> high latency and blocking [check]
Hint: No cache means blocking queries until authoritative response [check]
Common Mistakes:
4. For a high-traffic public API requiring both strong security and minimal latency, which TLS configuration trade-off is most appropriate?
medium
A. Use TLS 1.3 with ephemeral key exchange to enable forward secrecy and reduce handshake latency
B. Use self-signed certificates to avoid certificate chain overhead
C. Disable certificate validation to speed up connections
D. Use TLS 1.0 with RSA key exchange for compatibility

Solution

  1. Step 1: Evaluate TLS versions and key exchange

    TLS 1.3 supports ephemeral key exchange (ECDHE) which provides forward secrecy and reduces handshake round trips, lowering latency.

  2. Step 2: Eliminate other options

    Use TLS 1.0 with RSA key exchange for compatibility uses outdated TLS 1.0 and RSA key exchange lacking forward secrecy and higher latency. Disable certificate validation to speed up connections compromises security by disabling validation. Use self-signed certificates to avoid certificate chain overhead risks trust issues and is unsuitable for public APIs.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TLS 1.3 ephemeral keys -> forward secrecy + lower latency [check]
Hint: TLS 1.3 ephemeral keys = forward secrecy + low latency [check]
Common Mistakes:
5. At 10x scale, which component fails first in a chat system and why?
hard
A. The chat servers fail first because WebSocket connections are stateful and cannot be resharded easily
B. The load balancer fails first because it cannot distribute 10x more TCP connections
C. The message queue fails first because Kafka partitions cannot be increased dynamically
D. The database fails first because it cannot handle 10x more writes without sharding

Solution

  1. Step 1: Identify stateful components limiting scale

    Chat servers maintain stateful WebSocket connections bound to server memory, limiting horizontal scaling.

  2. Step 2: Compare other components' scalability

    Databases can be sharded; Kafka partitions can be increased; load balancers scale horizontally. Stateful chat servers cannot easily move existing connections.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket servers bottleneck scaling first [check]
Hint: Stateful WebSocket servers block scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard