Bird
Raised Fist0

TCP vs UDP - When Reliability Matters and When Speed Wins

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Protocol Router

Receives incoming message and inspects delivery requirement

Determines if message requires reliability (TCP) or speed (UDP)

Protocol:TCP or UDP
BeforeMessage received from client with delivery preference flag
AfterMessage routed to TCP Handler for reliable or UDP Handler for fast processing
TCP Handler

Accepts message over TCP connection

Ensures ordered, reliable delivery via WebSocket

Protocol:WebSocket
BeforeMessage routed to TCP Handler but not yet acknowledged
AfterMessage acknowledged and forwarded to Reliable Message Processing
Reliable Message Processing

Processes message ensuring durability and ordering

Publishes message to Kafka for durable storage

Protocol:Kafka
BeforeMessage received from TCP Handler, not yet stored
AfterMessage durably committed to Kafka; ready for storage
Storage Layer

Stores message persistently

Writes message to durable storage for later retrieval

Protocol:Kafka consumer
BeforeMessage committed in Kafka but not yet stored
AfterMessage safely stored; available for client retrieval
UDP Handler

Receives message over UDP

Accepts fast, unordered packets without connection overhead

Protocol:UDP
BeforeMessage routed to UDP Handler, no delivery guarantees
AfterMessage forwarded immediately to Real-time Message Processing
Real-time Message Processing

Processes message prioritizing low latency

Streams message data to Analytics Layer for immediate insights

Protocol:HTTP
BeforeMessage received from UDP Handler, not yet analyzed
AfterMessage data streamed to Analytics Layer for real-time analysis
Analytics Layer

Consumes real-time message data

Performs analytics on fast message streams for monitoring

Protocol:HTTP
BeforeMessage data arriving from Real-time Message Processing
AfterAnalytics updated with latest message metrics
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│  Protocol Router  │
└─────────┬─────────┘
          │ TCP or UDP
          ▼
┌───────────────┐
│  TCP Handler  │
└──────┬────────┘
       │ WebSocket
       ▼
┌───────────────────────┐
│ Reliable Msg Proc     │
└──────────┬────────────┘
           │ Kafka
           ▼
    ┌───────────────┐
    │ Storage Layer │
    └───────────────┘
           ▲
           │
┌──────────┴────────┐
│ UDP Handler       │
└─────────┬─────────┘
          │ UDP
          ▼
┌───────────────────────┐
│ Real-time Msg Proc    │
└──────────┬────────────┘
           │ HTTP
           ▼
    ┌─────────────────┐
    │ Analytics Layer │
    └─────────────────┘
Design Rationale

This architecture demonstrates how a Protocol Router directs messages based on reliability needs. Messages requiring guaranteed delivery use TCP Handler and Reliable Message Processing, ensuring ordered, durable storage via Kafka and the Storage Layer. Conversely, messages prioritizing speed use UDP Handler and Real-time Message Processing, streaming data rapidly to the Analytics Layer for immediate insights. This separation balances the trade-offs between TCP's reliability and UDP's low latency, enabling the system to handle diverse application requirements efficiently.

Primary Focus

✓

Practice

(1/5)
1. A full-text search system must handle millions of document updates per second and ensure near real-time search availability. Which component is best suited to buffer and decouple the high write throughput from the indexing process?
easy
A. Use a relational database with batch update triggers to update the index
B. Use a distributed log system like Kafka to buffer document update events
C. Use a distributed cache like Redis to store the entire inverted index in memory
D. Use a message queue with at-least-once delivery but no ordering guarantees

Solution

  1. Step 1: Identify buffering component for high write throughput

    Relational DBs with triggers (A) are not designed for millions of writes per second and cause blocking. Redis (C) is fast but storing entire inverted index in memory is not durable or scalable. Message queues without ordering (D) risk out-of-order updates causing index inconsistency.

  2. Step 2: Evaluate Kafka's suitability

    Kafka provides durable, ordered, partitioned logs that can buffer high write rates and decouple ingestion from indexing, enabling near real-time processing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka buffers high write throughput with ordering and durability [check]
Hint: Kafka buffers writes with ordering and durability [check]
Common Mistakes:
2. A team must decide between using a detailed blame-focused report or a blameless timeline with action items for their post-mortem. Which approach is best for fostering continuous improvement in a high-trust engineering culture?
medium
A. Use blameless timelines with actionable steps to encourage learning and improvement
B. Use blame-focused reports to enforce accountability and prevent future errors
C. Use only automated logs without human analysis to avoid bias
D. Skip post-mortems entirely to save time and avoid conflict

Solution

  1. Step 1: Evaluate cultural impact of blame vs blameless approaches

    Blame-focused reports create fear and reduce openness, harming continuous improvement.

  2. Step 2: Assess effectiveness of blameless timelines with action items

    They foster trust, encourage learning, and drive actionable improvements aligned with high-trust culture.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Blameless + action items -> continuous improvement [check]
Hint: Blameless + action items build trust and improve systems [check]
Common Mistakes:
3. Without a clear action item tracking system after a post-mortem, what specific failure occurs in the incident resolution process?
medium
A. The root cause analysis becomes inaccurate due to missing data
B. Action items are forgotten or delayed, causing repeated incidents
C. Incident detection slows down because alerts are not configured
D. The blame culture intensifies as no one is held accountable

Solution

  1. Step 1: Identify role of action item tracking

    Tracking ensures follow-through on improvements, preventing recurrence and reducing blame.

  2. Step 2: Trace failure without tracking

    Without tracking, accountability gaps appear, blame culture can worsen as no clear ownership exists.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No tracking -> blame culture intensifies due to lack of ownership [check]
Hint: No tracking -> blame culture grows, fixes stall [check]
Common Mistakes:
4. If the HTTP/2 connection's TCP layer experiences packet loss, what is the exact failure mode affecting multiplexed streams?
medium
A. All multiplexed streams stall due to TCP head-of-line blocking until lost packets are retransmitted
B. HTTP/2 switches to HTTP/1.1 fallback automatically to avoid stalls
C. The connection resets immediately causing all streams to fail
D. Only the lost stream stalls; other streams continue unaffected

Solution

  1. Step 1: Understand TCP head-of-line blocking impact

    TCP guarantees ordered delivery, so packet loss stalls all streams multiplexed on the connection until retransmission completes.

  2. Step 2: Eliminate incorrect failure modes

    Only one stream stalling is false due to TCP ordering; connection reset or fallback does not happen automatically.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TCP loss stalls all HTTP/2 streams due to head-of-line blocking [check]
Hint: TCP loss stalls all HTTP/2 streams due to ordering [check]
Common Mistakes:
5. At 10x scale, which component in a chat system fails first and why?
hard
A. The database fails first due to write amplification and disk I/O bottlenecks
B. The load balancer fails first because it cannot handle the increased connection count
C. Chat servers fail first because WebSocket connections are stateful and cannot be resharded easily
D. The message queue fails first due to partition leader overload

Solution

  1. Step 1: Analyze stateful components at scale

    Chat servers maintain WebSocket connections statefully; scaling requires connection migration or sticky sessions.

  2. Step 2: Identify bottleneck

    At 10x scale, chat servers hit connection limits and cannot shard existing connections, causing failure before DB or load balancer.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers -> scaling bottleneck due to connection affinity [check]
Hint: Stateful WebSocket servers block scaling before DB or load balancer [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