Bird
Raised Fist0

WebSockets vs Long Polling vs Server-Sent Events - When to Use Each

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
🎯
WebSockets vs Long Polling vs Server-Sent Events - When to Use Each
45 min · senior
senior

You are designing a real-time notification system for a startup with 50 million daily active users (DAU). The system must deliver messages with P99 latency under 200ms, support end-to-end encryption, and handle offline message delivery. The system should choose the appropriate communication protocol (WebSockets, Long Polling, or Server-Sent Events) based on use case and constraints.

  • End-to-end encryption required for all messages
  • Support offline message delivery with guaranteed eventual consistency
  • P99 message delivery latency under 200ms
  • Clients include mobile and web browsers with varying network conditions
  • Server infrastructure must scale to 50M DAU with peak concurrency of 5M connections
📋
Guided Steps
1/5
Step 1
Choosing the Right Protocol per Use Case
Given the constraints, how do you decide when to use WebSockets, Long Polling, or Server-Sent Events for different client scenarios?
💡 Hint
Consider bidirectional communication needs, browser support, and network overhead for each protocol.
Use WebSockets (via AWS API Gateway WebSocket API) for bidirectional, low-latency communication; Server-Sent Events (SSE) for unidirectional streaming with simpler client support; Long Polling (HTTP/2 with NGINX) only as fallback for legacy clients or restrictive networks.
Mid: Names WebSockets for real-time, SSE for streaming, Long Polling fallback. Senior: Explains WebSocket stateful connection benefits, SSE’s HTTP/1.1 unidirectional streaming limitations, and Long Polling’s overhead causing scalability issues at 50M DAU.
⚠️Common Wrong Answer
Choosing Long Polling as primary protocol - leads to excessive HTTP connection churn and server overload at scale.
Step 2
Ensuring End-to-End Encryption and Secure Connections
How do you architect the system to guarantee end-to-end encryption for messages over these protocols?
💡 Hint
Think about TLS termination points and message encryption at the application layer.
Terminate TLS at AWS ELB with mutual TLS for client authentication, then use application-layer encryption (e.g., libsodium) for message payloads to ensure end-to-end encryption beyond transport layer.
Mid: Mentions TLS for transport security. Senior: Explains why TLS alone is insufficient for end-to-end encryption, details application-layer encryption to prevent server-side plaintext exposure.
⚠️Common Wrong Answer
Relying solely on TLS termination at load balancer - exposes plaintext messages inside backend, violating end-to-end encryption.
Step 3
Handling Offline Delivery and Message Synchronization
How does the system guarantee offline message delivery and allow clients to sync missed messages after reconnecting?
💡 Hint
Consider durable storage and cursor-based synchronization mechanisms.
Use Apache Kafka with topic partition keyed by user_id to store messages durably; clients maintain last received offset to fetch missed messages on reconnect, enabling exactly-once delivery semantics.
Mid: Suggests durable storage for offline messages. Senior: Explains Kafka partitioning by user_id ensures message order and efficient range queries for cursor-based sync, avoiding duplicates and gaps.
⚠️Common Wrong Answer
Using a relational DB for message storage - causes high write amplification and slow range queries at 50M DAU scale.
Step 4
Meeting P99 Latency Under 200ms at Scale
What architectural choices ensure P99 message delivery latency under 200ms for 5M concurrent connections?
💡 Hint
Focus on connection management, load balancing, and message fan-out strategies.
Use AWS API Gateway WebSocket API with auto-scaling backend Lambda workers consuming Kafka streams; employ Redis Streams for fan-out and connection state caching to minimize latency and avoid hot spots.
Mid: Names scalable backend and caching. Senior: Details how Redis Streams reduce fan-out latency, how API Gateway manages connection state efficiently, and how Lambda concurrency scales elastically to maintain P99 latency.
⚠️Common Wrong Answer
Using a monolithic server for WebSocket connections - leads to connection saturation and latency spikes.
Step 5
Designing APIs for Multi-Protocol Support
Sketch the 3 core API endpoints that support WebSockets, Long Polling, and SSE clients, considering connection initiation, message sync, and acknowledgments.
💡 Hint
Think about connection upgrade, polling endpoints, and ACK message formats.
Define: 1) /connect endpoint for WebSocket handshake or SSE stream initiation; 2) /poll endpoint for Long Polling HTTP GET with timeout; 3) /ack endpoint for clients to confirm message receipt, updating Kafka consumer offsets and Redis state.
Mid: Lists endpoints for connect, poll, and ack. Senior: Explains protocol-specific handshake details, how ack updates enable offline delivery guarantees, and how endpoints integrate with backend Kafka and Redis.
⚠️Common Wrong Answer
Designing a single generic HTTP endpoint without protocol-specific handling - causes inefficient client-server interaction and protocol incompatibility.
🔌
API Design Challenge
Sketch 3 core API endpoints for the real-time notification system that supports WebSockets, Long Polling, and Server-Sent Events.
  • How does the client initiate and maintain a connection for each protocol?
  • How does the client synchronize missed messages after reconnecting?
  • How does the client acknowledge receipt of messages to support offline delivery?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Correct protocol choice per use case with scale reasoning
  • End-to-end encryption beyond TLS with application-layer encryption
  • Durable message storage with Kafka partitioning for offline delivery
  • API endpoints supporting protocol-specific connection and sync
  • Latency optimization via Redis Streams and scalable connection management
Good to Have - 30%
  • Mutual TLS for client authentication
  • Fallback strategies for legacy clients
  • Detailed explanation of Kafka consumer offset management
  • Discussion of connection state caching trade-offs
Bonus - 10%
  • Consideration of mobile vs web client differences
  • Handling network partition and reconnection strategies
  • Use of AWS Lambda auto-scaling for backend workers
Using Long Polling as primary protocol causes excessive HTTP connection churn and server overload at 50M DAU scale, leading to system collapse.
Relying solely on TLS termination at load balancer exposes plaintext messages inside backend, violating end-to-end encryption guarantees.
Using a relational database for message storage at 50M DAU causes high write amplification and slow range queries, degrading performance.
Using a monolithic server for WebSocket connections leads to connection saturation and latency spikes, failing to meet P99 latency requirements.
Designing a single generic HTTP endpoint without protocol-specific handling causes inefficient client-server interaction and protocol incompatibility.
✅
Model Answer
▼ Reveal

This design uses AWS API Gateway WebSocket API for scalable bidirectional communication, Apache Kafka partitioned by user_id for durable message storage and offline delivery, Redis Streams for low-latency fan-out and connection state caching, and application-layer encryption with libsodium to ensure true end-to-end encryption beyond TLS. The system supports WebSockets, SSE, and Long Polling protocols with dedicated API endpoints for connection management, message synchronization, and acknowledgments. Mutual TLS at AWS ELB secures transport and authenticates clients. The architecture scales to 50M DAU with 5M concurrent connections, maintaining P99 latency under 200ms.

  • Use AWS API Gateway WebSocket API to handle 5M concurrent WebSocket connections with auto-scaling Lambda backend workers consuming Kafka streams.
  • Partition Kafka topics by user_id to ensure ordered, durable message storage and enable cursor-based synchronization for offline delivery.
  • Employ Redis Streams to reduce fan-out latency and cache connection state, minimizing hot spots and meeting P99 latency targets.
  • Implement application-layer encryption with libsodium to guarantee end-to-end encryption beyond TLS transport layer, preventing plaintext exposure in backend.
  • Use mutual TLS at AWS ELB for client authentication and secure TLS termination.
  • Support Long Polling via NGINX HTTP/2 as a fallback for legacy clients or restrictive networks, avoiding primary reliance on it due to scalability issues.
  • Design three core API endpoints: /connect for WebSocket handshake or SSE stream initiation, /poll for Long Polling HTTP GET with timeout, and /ack for clients to confirm message receipt and update Kafka offsets and Redis state.
  • AWS API Gateway WebSocket API for scalable, managed WebSocket connections supporting 5M concurrent clients
  • Apache Kafka with user_id partition key for durable, ordered message storage enabling offline delivery and cursor-based sync
  • Redis Streams for low-latency fan-out and connection state caching to meet P99 < 200ms latency
  • Application-layer encryption using libsodium to ensure true end-to-end encryption beyond TLS transport
  • NGINX HTTP/2 Long Polling fallback for legacy clients with restrictive network environments
  • Mutual TLS at AWS ELB for client authentication and secure transport termination
  • /connect, /poll, and /ack REST/WebSocket endpoints designed to handle protocol-specific connection management and message acknowledgments

Practice

(1/5)
1. In a system trace, at step 4 the circuit breaker checks the failure count before forwarding a request. What happens if the failure count exceeds the threshold at this step?
easy
A. The circuit breaker opens and immediately returns an error without calling downstream
B. The request is forwarded but logged for monitoring
C. The circuit breaker retries the request twice before opening
D. The request is queued until the downstream service recovers

Solution

  1. Step 1: Trace circuit breaker decision at Step 4

    When failure count exceeds threshold, the circuit breaker transitions to OPEN state and stops forwarding requests.
  2. Step 2: Understand behavior on open circuit

    Requests are immediately failed (B), not forwarded (A), retried (C), or queued (D).
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Open circuit returns error immediately without downstream call [check]
Hint: Open circuit returns error immediately, no downstream call [OK]
Common Mistakes:
2. In a sliding window rate limiter, at step 3 the system records a new request timestamp. What happens internally to the stored counters at this step?
easy
A. Old timestamps outside the sliding window are removed before adding the new timestamp
B. The leaky bucket drains tokens at a fixed rate before accepting the request
C. The token bucket refills tokens based on elapsed time before decrementing
D. The fixed window counter resets to zero if the current minute changed

Solution

  1. Step 1: Understand sliding window counter mechanics

    Sliding window counters maintain timestamps of recent requests and remove those outside the window to keep an accurate count.
  2. Step 2: At step 3, old timestamps beyond the window are purged before adding the new request timestamp

    This ensures the count reflects only requests within the sliding window duration.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Sliding window removes expired timestamps before counting new requests [check]
Hint: Sliding window purges old timestamps before counting new ones [check]
Common Mistakes:
3. In a system where a user requests access to a protected resource, at step 4 the Authorization Service checks the user's access token. What happens if the token is expired at this step?
easy
A. The Authorization Service forwards the request to the Resource Server without validation
B. The Authorization Service grants access but logs a warning for token expiry
C. The Authorization Service refreshes the token automatically and proceeds
D. The Authorization Service rejects the request and returns an HTTP 401 Unauthorized error

Solution

  1. Step 1: Understand Authorization Service behavior at token validation

    The service validates token expiry and rejects expired tokens.
  2. Step 2: Eliminate incorrect behaviors

    Granting access with expired token violates security; automatic refresh is done by Authentication Service, not Authorization; forwarding without validation breaks security.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Expired tokens cause 401 Unauthorized rejection [check]
Hint: Expired token -> Authorization rejects with 401 Unauthorized [check]
Common Mistakes:
4. For a system tracking SLO error budgets with high write volume and low latency requirements, which architecture is best suited to ensure accurate, near real-time error budget updates?
medium
A. Batch processing error logs every hour using Hadoop MapReduce
B. Polling a relational database every minute for error counts and updating budgets
C. Stream processing with Apache Flink to compute error budgets continuously
D. Using a time-series database with hourly rollups for error budget calculation

Solution

  1. Step 1: Analyze latency and accuracy requirements

    Near real-time updates require continuous stream processing rather than batch or polling.
  2. Step 2: Evaluate each architecture against these requirements

    Batch processing (A) and hourly rollups (D) are too slow; polling (C) introduces latency and load spikes; stream processing (B) provides continuous, low-latency computation.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Stream processing -> continuous, low-latency error budget updates [check]
Hint: Stream processing fits low latency and high write volume best [OK]
Common Mistakes:
5. At 10x traffic scale, which component in a system using a Reverse Proxy, API Gateway, and Load Balancer is most likely to become the bottleneck first, and why?
hard
A. API Gateway, because it performs CPU-intensive tasks like authentication and request transformation on every request
B. Load Balancer, because it maintains stateful TCP connections that cannot be easily sharded
C. Reverse Proxy, because it caches responses and runs out of memory under high load
D. DNS load balancing, because it cannot dynamically adjust to rapid traffic changes

Solution

  1. Step 1: Analyze component scaling characteristics

    Load Balancers typically handle stateless TCP connections and can be scaled horizontally; Reverse Proxies cache but can be scaled with eviction policies; DNS load balancing is not a runtime bottleneck.
  2. Step 2: Identify CPU-intensive bottleneck

    API Gateway performs authentication, rate limiting, and transformations per request, which are CPU and memory intensive and harder to scale linearly.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    API Gateway CPU load scales with request complexity, causing bottleneck [check]
Hint: API Gateway CPU-heavy tasks cause first bottleneck at scale [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