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
45 min · senior
senior

You are designing a real-time messaging platform for a startup with 50 million daily active users (DAU). The system must support encrypted message delivery with offline message persistence, and guarantee P99 end-to-end latency under 200ms for interactive chat. Some use cases prioritize reliability (e.g., financial alerts), while others prioritize speed (e.g., live game state updates). You must decide when to use TCP or UDP protocols and design the system accordingly.

Constraints
  • End-to-end encryption mandatory for all messages
  • Offline message delivery required with guaranteed eventual consistency
  • P99 latency must be under 200ms for interactive messages
  • System must handle 50M DAU with peak 1B messages per day (~11.5K msg/sec)
  • Support both reliable and low-latency message types with protocol choice
📋
Guided Steps
1/5
Step 1
Choosing Transport Protocol per Message Type
How would you decide when to use TCP vs UDP for different message types in this system?
💡 Hint
Consider the trade-offs between reliability guarantees and latency requirements for each message category.
Key Decision
Use TCP (e.g., TLS over TCP) for messages requiring guaranteed delivery and ordering, and UDP (e.g., QUIC or DTLS) for low-latency messages where occasional loss is acceptable.
Interviewer Expectation
Mid: Names TCP for reliability and UDP for speed. Senior: Explains TCP’s handshake and retransmission overhead causing latency spikes, and how QUIC over UDP mitigates head-of-line blocking while balancing encryption and speed.
⚠️Common Wrong Answer
Using TCP for all messages - leads to unnecessary latency for real-time updates and poor user experience under high load.
Step 2
Ensuring End-to-End Encryption over Both Protocols
How would you implement encryption to secure messages over TCP and UDP transports?
💡 Hint
Think about TLS for TCP and DTLS or QUIC for UDP, and how session management differs.
Key Decision
Use TLS 1.3 over TCP connections and DTLS 1.3 or QUIC for UDP to provide equivalent encryption guarantees with minimal handshake overhead.
Interviewer Expectation
Mid: Mentions TLS for TCP and DTLS for UDP. Senior: Details how QUIC integrates encryption and multiplexing over UDP, reducing handshake latency compared to DTLS, and how session resumption improves P99 latency.
⚠️Common Wrong Answer
Skipping encryption on UDP to save latency - violates security constraints and exposes data to interception.
Step 3
Handling Offline Message Delivery and Sync
How would you design offline message persistence and client sync mechanisms given mixed protocol usage?
💡 Hint
Consider durable storage and client-side cursor-based sync to handle missed messages reliably.
Key Decision
Persist messages in Apache Cassandra with partition key as conversation_id for efficient range queries; clients sync missed messages over TCP-based APIs ensuring reliability.
Interviewer Expectation
Mid: Suggests durable storage and client polling. Senior: Explains Cassandra’s LSM-tree writes scale linearly at 50M DAU, and why conversation_id partitioning enables O(1) range scans for cursor-based sync, avoiding out-of-order delivery.
⚠️Common Wrong Answer
Using UDP for offline sync - unreliable delivery causes message loss and inconsistent client state.
Step 4
Designing APIs to Support Protocol Flexibility
What core API endpoints would you design to support sending, receiving, and acknowledging messages with TCP and UDP?
💡 Hint
Think about endpoints that allow clients to specify reliability preference, sync missed messages, and confirm receipt.
Key Decision
Design SendMessage (POST /messages) with reliability flag to choose TCP or UDP transport; SyncMessages (GET /messages/sync) over TCP for offline recovery; AcknowledgeMessage (POST /messages/ack) over TCP to confirm delivery.
Interviewer Expectation
Mid: Names basic send and receive endpoints. Senior: Explains how SendMessage API abstracts transport choice, SyncMessages ensures eventual consistency over TCP, and AcknowledgeMessage enables exactly-once semantics for reliable messages.
⚠️Common Wrong Answer
Single endpoint using only UDP - causes message loss and no offline recovery.
Step 5
Scaling and Monitoring Protocol Usage
How would you monitor and scale the system to handle 50M DAU with mixed TCP/UDP traffic?
💡 Hint
Consider metrics for latency, packet loss, retransmissions, and how to autoscale protocol-specific components.
Key Decision
Use Prometheus and Grafana to monitor TCP retransmissions, UDP packet loss, and latency; autoscale TCP connection pools and UDP worker nodes independently based on traffic patterns.
Interviewer Expectation
Mid: Mentions monitoring latency and errors. Senior: Details specific TCP metrics like retransmission rate, UDP packet loss counters, and how autoscaling TCP proxies (e.g., Envoy) and UDP servers separately prevents resource contention.
⚠️Common Wrong Answer
Treating TCP and UDP traffic identically in scaling - leads to resource exhaustion and degraded P99 latency.
🔌
API Design Challenge
Sketch 3 core API endpoints for the messaging system that handle sending, receiving, and acknowledging messages considering TCP and UDP trade-offs.
Hints
  • How does the client send messages with reliability or speed preference?
  • How does the client sync missed messages after offline periods?
  • How does the recipient acknowledge message receipt to ensure reliability?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Clear distinction between TCP and UDP usage based on reliability vs latency
  • Use of TLS for TCP and DTLS or QUIC for UDP encryption
  • Offline message persistence with Cassandra partitioned by conversation_id
  • API design supporting reliability flags and offline sync over TCP
Good to Have - 30%
  • Monitoring TCP retransmissions and UDP packet loss with Prometheus
  • Autoscaling TCP and UDP components separately
  • Explanation of QUIC benefits over plain UDP or DTLS
Bonus - 10%
  • Discussion of session resumption to reduce handshake latency
  • Handling exactly-once delivery semantics via acknowledgments
Anti-patterns to Avoid
Using TCP exclusively for all messages causes high latency spikes under load, degrading user experience and system scalability.
Skipping encryption on UDP to save latency violates security and compliance, exposing sensitive data to interception and attacks.
Using UDP for offline message sync leads to message loss and inconsistent client state due to unreliable delivery.
Single autoscaling strategy for TCP and UDP causes resource contention and degraded P99 latency because of differing traffic characteristics.
Ignoring protocol-specific telemetry prevents proactive detection of retransmissions or packet loss, leading to undiagnosed performance issues.
✅
Model Answer
▼ Reveal

This design balances the trade-offs between TCP and UDP protocols to meet strict latency and reliability requirements for a 50M DAU messaging platform. It uses TLS 1.3 over TCP for reliable, ordered, encrypted delivery and QUIC or DTLS over UDP for low-latency encrypted transport. Offline message persistence is implemented with Apache Cassandra partitioned by conversation_id to enable efficient range queries and cursor-based client sync over TCP. APIs abstract transport choice with reliability flags and support acknowledgments for exactly-once delivery. Monitoring with Prometheus and Grafana tracks protocol-specific metrics, and autoscaling is done independently for TCP and UDP components to optimize resource usage.

Key Decisions
  • Use TLS 1.3 over TCP for messages requiring guaranteed delivery and ordering
  • Use QUIC or DTLS over UDP for low-latency messages where occasional loss is acceptable
  • Persist messages in Apache Cassandra partitioned by conversation_id for efficient offline sync
  • Design APIs with reliability flags to select TCP or UDP transport and support cursor-based sync over TCP
  • Monitor TCP retransmissions and UDP packet loss separately using Prometheus metrics
  • Autoscale TCP and UDP components independently based on traffic patterns to maintain P99 latency
  • TLS 1.3 over TCP for reliable, ordered, encrypted delivery with congestion control
  • QUIC protocol over UDP for low-latency encrypted transport with multiplexing and reduced handshake
  • Apache Cassandra with conversation_id partition key for scalable offline message persistence and efficient range queries
  • Client APIs that abstract transport choice with reliability flags and support cursor-based sync over TCP
  • Prometheus + Grafana for protocol-specific telemetry including TCP retransmissions and UDP packet loss
  • Autoscaling TCP connection pools and UDP worker nodes independently to handle mixed traffic patterns
  • Use of DTLS or QUIC for encryption over UDP to meet security requirements without sacrificing speed
  • Cursor-based client sync to guarantee eventual consistency after offline periods using TCP transport

Practice

(1/5)
1. In a system where an API Gateway sits in front of multiple microservices, at step 3 of the request flow, the API Gateway performs authentication. What happens if the authentication fails at this step?
easy
A. The request is forwarded to the backend microservice without modification
B. The API Gateway immediately returns an error response to the client without forwarding the request
C. The Load Balancer retries the request to another API Gateway instance
D. The Reverse Proxy caches the failed authentication response for future requests

Solution

  1. Step 1: Understand API Gateway behavior at authentication step

    API Gateway enforces authentication and blocks unauthorized requests before forwarding.

  2. Step 2: Trace failure handling

    On authentication failure, the API Gateway returns an error response immediately, preventing backend load.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    API Gateway blocks unauthorized requests early [check]
Hint: Auth fails at API Gateway -> immediate error response [check]
Common Mistakes:
2. You must design a distributed key-value store that tolerates network partitions and prioritizes availability over consistency. Which consensus approach fits best?
medium
A. Use Raft to enforce strong consistency with leader election
B. Use Paxos to guarantee consensus before any write is committed
C. Use eventual consistency with conflict resolution, avoiding strict consensus
D. Use a centralized lock service to serialize all writes

Solution

  1. Step 1: Analyze CAP trade-offs

    Prioritizing availability over consistency during partitions means relaxing strict consensus.

  2. Step 2: Evaluate options

    Raft and Paxos enforce strong consistency, sacrificing availability; centralized locks create single points of failure; eventual consistency allows availability with conflict resolution.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Eventual consistency favors availability during partitions [check]
Hint: Availability over consistency -> eventual consistency with conflict resolution [check]
Common Mistakes:
3. For a system with frequent feature toggles and multiple teams deploying daily, which approach best balances deployment speed and risk mitigation?
medium
A. Rely solely on Canary deployments without feature flags
B. Use Blue-Green deployment exclusively for all releases
C. Combine Feature Flags for gradual feature exposure with Canary deployments for version rollout
D. Use Rolling deployments with manual rollback procedures

Solution

  1. Step 1: Identify constraints

    Frequent deployments and multiple teams require fast, low-risk releases.

  2. Step 2: Evaluate options

    Blue-Green alone is heavy for frequent deploys; Canary alone lacks feature granularity; Rolling with manual rollback is slow and risky.

  3. Step 3: Combine Feature Flags and Canary

    Feature Flags enable gradual feature exposure; Canary controls version rollout risk.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Feature Flags + Canary balance speed and risk for frequent deploys [check]
Hint: Feature Flags + Canary = fast, safe multi-team deploys [OK]
Common Mistakes:
4. For a global load balancer needing fast failover and minimal client disruption, which architecture is best suited?
medium
A. Client-side DNS failover with low TTLs
B. Passive health detection relying on client error reports
C. Active health checks with centralized state and instant routing updates
D. Round-robin DNS without health checks

Solution

  1. Step 1: Evaluate failover speed and client impact

    Active health checks with centralized state enable immediate detection and routing updates, minimizing disruption.

  2. Step 2: Eliminate other architectures

    Client-side DNS failover is slow due to DNS caching; passive detection delays failover; round-robin DNS lacks health awareness.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Centralized active health checks enable fast, seamless failover [check]
Hint: Centralized active health checks enable instant failover [check]
Common Mistakes:
5. At 10x traffic scale, which component in a CDN-backed architecture is most likely to fail first and why?
hard
A. Global load balancers, as they cannot distribute traffic evenly at extreme scale
B. Origin servers, due to inability to handle increased cache miss requests
C. CDN edge servers, because limited cache storage causes frequent origin fetches
D. DNS resolvers, since they become overwhelmed by increased domain resolution requests

Solution

  1. Step 1: Analyze CDN edge server cache storage limits

    At 10x scale, edge caches may evict content more frequently, increasing origin fetches.

  2. Step 2: Recognize increased origin fetches overload origin servers but edge cache misses spike first

    Edge servers become bottlenecks due to cache capacity and eviction policies before origin overload.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Edge cache storage limits cause first failure at scale, not origin or load balancers [check]
Hint: Edge cache storage limits cause origin fetch spikes first at scale [OK]
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