Real Time Data and Communication Questions

Covers designing and implementing real time client server communication and data flows. Topics include transport mechanisms such as WebSockets, Server Sent Events, long polling and regular polling with appropriate intervals; connection lifecycle management including reconnection strategies, exponential backoff, and error recovery; data synchronization patterns including optimistic updates, conflict resolution, reconciliation strategies, and eventual consistency; offline first approaches, caching strategies, and state reconciliation when network connectivity is restored. Also includes streaming concerns such as memory management, backpressure, batching and windowing, message ordering and idempotency, sequencing and versioning, and techniques for broadcasting and multicasting data to multiple clients using pub sub or message broker architectures. Considerations for authentication and authorization over realtime channels, scalability and load balancing for persistent connections, monitoring and observability, and trade offs between latency, consistency and throughput are also assessed. Candidates may be asked to design end to end solutions, justify technology choices, and explain implementation details and failure modes.

HardTechnical

46 practiced

Design and provide pseudocode for a server-side backpressure policy that, upon crossing a memory threshold, selectively drops, compresses, or aggregates messages per-client priority. The policy should preserve high-priority messages, emit metrics for dropped messages, and support graceful degradation. Explain rollout strategy and safety guards to avoid broad customer impact.

Sample Answer

Approach: maintain per-client priority queues and global memory tracked by an allocator. When memory > threshold, apply graduated policy: 1) refuse/ drop low-priority messages, 2) compress medium-priority messages (batch + compress), 3) aggregate/ coalesce low-volume clients, while always preserving high-priority messages. Emit metrics for drops/compressions and support graceful degradation (backoff hints, rate-limited reinstatement).

Pseudocode (Python-style):

python

# thresholds (bytes)
MEM_WARN = 0.7 * MEM_CAP
MEM_CRITICAL = 0.9 * MEM_CAP

# per-client structures
clients = { client_id: { "queues": { "high":[], "med":[], "low":[] }, "meta": {...} } }

def current_memory() -> int:
    return allocator.allocated_bytes()

def apply_backpressure():
    mem = current_memory()
    if mem < MEM_WARN:
        return  # healthy

    # Step 1: protect high priority
    preserve_high()

    # Step 2: graduated actions
    if mem >= MEM_CRITICAL:
        # aggressive: drop low, compress med, aggregate opportunistically
        drop_low_priority()
        compress_medium_priority(batch=True)
        aggregate_small_clients()
        emit_metric("backpressure.mode","critical")
    else:
        # moderate: only compress medium and delay low
        compress_medium_priority(batch=False)
        delay_low_priority_with_backoff()
        emit_metric("backpressure.mode","warn")

    record_metrics()

def drop_low_priority():
    for cid in clients:
        while memory_exceeds(MEM_CRITICAL) and clients[cid]["queues"]["low"]:
            msg = clients[cid]["queues"]["low"].pop(0)
            allocator.free(msg)
            emit_metric("messages.dropped", {"client":cid, "priority":"low"})

# compression and aggregation helpers omitted for brevity

Key concepts:- Prioritized queues ensure high-priority unaffected.- Actions are ordered: delay -> compress -> aggregate -> drop.- Emit detailed metrics (dropped_count, compressed_bytes_saved, affected_clients).- Graceful degradation: send backoff hint to clients, rate-limit recovery, and incremental rollbacks.

Rollout strategy & safety guards:- Feature-flag rollout per region/cluster; start with internal customers.- Canary small % of traffic, monitor error budget, drop-rate, latency.- Kill-switch and automated rollback if >X% increase in high-priority latency or error-rate.- Per-customer caps to avoid noisy-neighbor effects; never drop high-priority beyond a tiny emergency rate.- Continuous visibility: dashboards and alerts for drop/compress events and SLO violations.

Edge cases:- Sudden spike from single client → enforce per-client token bucket.- Persistent memory leak → pair with OOM monitors and auto-scale/evict policy.

EasyTechnical

44 practiced

You need to implement a live sports score update feed (server-to-client streaming, many clients) with low latency but mostly one-way data. Between SSE and WebSockets which would you choose and why? Consider scalability, proxies/CDNs, mobile clients, TLS, automatic reconnection behavior, and how to implement efficient fan-out to many clients.

Sample Answer

I would choose Server-Sent Events (SSE) for a live sports score feed if the traffic pattern is overwhelmingly one-way (server -> client), with occasional client messages (e.g., subscribe/unsubscribe). SSE uses simple HTTP connections, has built-in reconnection/backoff, keeps events ordered, and is lighter-weight than WebSockets for uni-directional streams — which simplifies proxies/CDNs and mobile behavior.

Why SSE vs WebSockets (considering your factors):- Scalability: SSE scales well behind HTTP load balancers and CDNs because it’s plain HTTP. For very large fan-out, use a pub/sub backbone (Redis Streams, NATS, Kafka) and stateless SSE frontends that subscribe to channels; the frontends push to their connected clients. WebSockets require sticky routing or stateful connection tracking, making autoscaling and LB configuration harder.- Proxies/CDNs: Many CDNs and corporate proxies handle long-lived HTTP connections and HTTP/1.1 chunked responses (SSE) more reliably than generic WebSocket proxies. Some CDNs now support WebSocket proxying but behavior is more heterogeneous.- Mobile clients & TLS: SSE works over HTTPS and is friendly to mobile HTTP stacks (easier to reconnect on network changes). WebSockets also work over TLS (wss://) but require additional handling on flaky mobile networks.- Automatic reconnection: SSE has built-in reconnect with Last-Event-ID support — simplifies resumed streams. WebSockets need custom reconnection and resume logic.- Latency: Both can be low-latency; SSE’s HTTP path introduces minimal overhead for text/event-stream. If you need binary frames or truly bi-directional low-latency RPC, WebSocket may be necessary.

Efficient fan-out architecture (how I’d implement as an SRE):- Pub/sub core: Ingest updates into a durable broker (Kafka/NATS/Redis Streams) to decouple producers and frontends.- Stateless edge pool: Horizontal pool of SSE servers (K8s) consuming relevant topics (partitioning by match/team) and pushing to connected clients. Keep servers stateless regarding subscription metadata in memory only; store durable state in broker for recovery.- Load balancing: Use plain HTTP LB (NGINX/Envoy/ALB) with health checks; no sticky sessions needed since SSE servers are subscribers.- CDN + edge caching: Cache static pages; for live data, consider edge workers (Cloudflare Workers, Fastly Compute) that connect to your pub/sub or use a regional fan-out service to reduce origin load.- Backpressure & autoscaling: Track connection counts/throughput, autoscale frontends, and throttle non-essential fields. Implement per-connection rate limits and metrics (latency, disconnects, reconnection rate).- Observability: Emit metrics (connections, events/sec, error rate), tracing for publish→deliver latency, and alert on SLO breaches.

When to pick WebSocket instead:- If you require low-overhead bi-directional communication, binary frames, or many small client-origin messages, choose WebSockets and accept extra complexity: connection affinity, custom reconnection/resume, and more careful proxy/CDN testing.

Overall: for a mostly one-way, low-latency, highly scalable sports feed I’d standardize on SSE + robust pub/sub backbone, with WebSockets only when bi-directional capabilities are required.

HardTechnical

66 practiced

Case study: Choose an end-to-end technology stack for a realtime multiplayer game (60Hz position updates, server-authoritative physics, up to 20k concurrent players). Justify choices for transport (UDP vs TCP/WebSocket), server runtime (language/framework), networking model, serialization format, broker or matchmaker, and strategies for cheat-prevention and latency compensation.

Sample Answer

Requirements & constraints:- 60 Hz authoritative tick, server-run physics- Up to 20k concurrent players- Low-latency realtime position updates, cheat-resistance, high availability

High-level architecture:- Control plane (matchmaker, lobby, metrics) + many identical game server instances (authoritative, tick @60Hz).- Shard by region / game-mode; each game server handles a limited player set (e.g., 50–200 players) and spatially partitioned entities (zones/quadtrees) to bound CPU/network.

Transport: UDP (with selective reliability)- Use UDP for realtime state (position/inputs) because of low head-of-line latency.- Use a proven UDP library like ENet or QUIC for connection management and optional ordered/reliable subchannels. QUIC is attractive for NAT traversal + built-in congestion control, but ENet-style custom stack gives tighter control.- Control messages (chat, auth, store transactions) over TLS/gRPC or WebSocket (TCP) separate from realtime UDP.

Server runtime / language:- Systems language for deterministic, high-throughput networking: Rust (tokio + async libs) or Go (netpoll + goroutines). Choose Rust for maximum latency consistency and memory safety; Go if faster dev velocity.- Use lightweight game-server framework or custom event loop that processes ticks deterministically and keeps per-tick budgets.

Networking model:- Server-authoritative: clients send input/intent; server simulates physics and emits authoritative snapshots.- Spatial interest management: partition world (zones, grids, quadtree) so servers send 60Hz updates only to players within interest region.- Snapshot delta encoding + per-client reliable ack channel for important events (kills, match end).- Tick loop: accept inputs, enqueue, simulate, produce snapshots. Use fixed timestep + substeps if needed.

Serialization:- Use a compact binary schema: FlatBuffers or Cap’n Proto for zero-copy deserialization, or protobuf with binary + custom delta encoding. FlatBuffers preferable for per-tick low allocation and speed.- Encode snapshots as delta frames (baseline + diffs) and compress with fast LZ4 if large bursts occur.

Broker / matchmaker:- Matchmaker service (stateless microservice) backed by Redis for ephemeral presence and matchmaking queues. Use gRPC for control-plane APIs.- Game server registry via service discovery (Consul or Kubernetes endpoints). Use leader election per region for autoscaling orchestration.- Use Kubernetes for orchestration, HPA (custom metrics) to scale game server group sizes; use node pools optimized for network performance (e.g., enhanced networking instances).

Cheat-prevention:- Server-authoritative physics and validation: never trust client positions; accept inputs only within plausible thresholds.- Input rate limiting, sanity checks (max speed, teleport detection), bounding-box movement checks, and server-side replay buffers to validate late inputs.- Cryptographic session tokens and signed client packets to reduce spoofing.- Tamper-detection: secure client builds and anti-tamper modules, but primary trust model is server.- Behavioral anomaly detection: stream events to a real-time analytics pipeline (Kafka) and run ML/heuristics to flag suspicious behavior for automated banning/marker queues.- Reproducible audit logs (append-only) for post-incident investigation.

Latency compensation:- Client-side prediction: simulate local inputs immediately.- Server reconciliation: on server snapshot authoritative state, client rolls back and replays unacknowledged inputs.- Lag compensation (rewind): when resolving actions like hits, server rewinds relevant entities to shooter’s perceived time window (within an allowed tolerance) to account for RTT.- Interpolation/extrapolation: clients render other players with interpolation of last few authoritative snapshots and bounded extrapolation to hide packet jitter.- Adaptive tick/packet strategies: important events reliably delivered; non-critical deltas lossy.

SRE & reliability considerations:- SLOs: define p99 latency <= X ms for position updates, availability 99.95% for control plane.- Observability: Prometheus metrics (tick latency, packet loss, queue sizes), Grafana dashboards, distributed tracing (Jaeger) for control plane, and eBPF-derived network telemetry for packet-level visibility.- Alerting: automated alerts for tick overruns, queue growth, packet loss, and host-level NIC saturation.- Capacity planning: benchmark per-instance player capacity under realistic physics load; overprovision headroom for spikes; use autoscaler with cushion.- Fault tolerance: graceful draining of game servers (move new joins elsewhere, let matches finish or migrate), state snapshots for quick recovery, region-aware replication.- Chaos & testing: inject packet loss/latency, run soak tests (k6 or custom load) up to 2x expected peak.- CI/CD & rollbacks: canary deployments, feature flags for physics changes, automated rollback on error budget breach.

Trade-offs:- UDP + custom reliability adds engineering cost but is necessary to meet latency and head-of-line requirements.- Rust gives consistent latency but longer dev ramp; Go speeds iteration with slightly higher tail latency.- QUIC simplifies NAT traversal but may hide low-level tuning available with a custom UDP stack.

This stack balances realtime latency, cheat-resistance, operational observability, and horizontal scalability for 20k concurrent players while keeping clear separation between control-plane reliability and realtime performance.

EasyTechnical

45 practiced

Compare WebSockets, Server-Sent Events (SSE), long polling, and regular polling for real-time client-server communication. For each transport explain: connection model (half/full-duplex), typical latency characteristics, browser/proxy support, server resource implications, and common use-cases (e.g., collaborative editing, live notifications, stock tickers). Conclude with recommended transport(s) for (a) a live chat app and (b) a server-to-many broadcasting system.

Sample Answer

Brief summary comparing transports:

WebSockets- Connection model: full-duplex persistent TCP (bi-directional).- Latency: very low (sub-100ms typical) once connection established.- Browser/proxy support: wide browser support; some legacy HTTP proxies may block or terminate if not WebSocket-aware.- Server resources: holds many long-lived TCP connections → needs evented servers, connection limits, load balancing (sticky sessions or proxy upgrades), memory per connection.- Use-cases: chat, collaborative editing, multiplayer games, low-latency bidirectional apps.

Server-Sent Events (SSE)- Model: half-duplex (server → client) over HTTP/1.1 (EventStream).- Latency: low for push updates; reconnects handled automatically.- Support: good in browsers except IE; works through proxies as normal HTTP.- Server resources: long-lived HTTP connections, lighter than WebSocket since only server→client; scales with connection count.- Use-cases: live notifications, news feeds, stock tickers (server-push only).

Long Polling- Model: pseudo full-duplex via repeated HTTP requests (client waits; server responds when data available).- Latency: moderate; typically slightly higher due to request/response overhead and re-establishment.- Support: universal (works through proxies).- Server resources: higher request churn and resource usage; needs efficient request handling (async servers).- Use-cases: legacy browsers, environments where WebSockets blocked, fallback for chat/notifications.

Regular Polling- Model: client-initiated polling at intervals (stateless requests).- Latency: higher and variable depending on interval.- Support: universal and simplest.- Server resources: predictable but potentially high aggregate load if interval small.- Use-cases: low-frequency updates, health checks, metrics.

Recommendations (SRE lens)- Live chat app: WebSockets — best for low-latency bi-directional communication; ensure autoscaling of connection brokers, use connection offload (nginx, envoy), implement keepalives and circuit-breakers.- Server-to-many broadcasting (one→many): SSE for pure server→client streams if browser support OK; otherwise WebSockets with pub/sub and fan-out via message broker (Redis/ Kafka) for wider flexibility and presence/ACKs. For very large fan-outs consider CDN/WebRTC or multicast-like architectures and use push gateways.

MediumTechnical

63 practiced

Explain how HTTP/2 and HTTP/3 change realtime streaming options compared to HTTP/1.1. Discuss multiplexing, server push, header compression, connection coalescing, and the impact on long-lived connections like SSE. When might you prefer HTTP/2/3 streaming over raw WebSockets?

Sample Answer

Brief answer up front: HTTP/2 and HTTP/3 significantly improve HTTP-based realtime streaming versus HTTP/1.1 by enabling safe concurrent streams on a single connection, reducing latency and head‑of‑line blocking (especially with HTTP/3), and compressing headers — but they add different flow-control and proxy behaviors that affect long‑lived streams (SSE). You’d pick HTTP/2/3 streaming when you want simpler HTTP-based delivery, many concurrent lightweight streams, or easier infra integration; choose WebSockets when you need low‑latency bidirectional binary messaging or guaranteed ordered, stateful socket semantics.

Key points

- Multiplexing - HTTP/1.1: one outstanding request per TCP connection (unless using many connections), so long‑lived streams (SSE) tie up a connection and limit concurrency. - HTTP/2: multiplexes many streams over one TCP/TLS connection using stream frames — removes the need for multiple TCP connections but still suffers TCP-level HOL: packet loss stalls all streams behind it. - HTTP/3: multiplexes over QUIC (UDP+TLS+streaming built-in) which provides per‑stream reliability and avoids TCP HOL, so other streams keep flowing when one stream loses packets.

- Header compression - HTTP/1.1: repeated headers are sent in full or via ad‑hoc compression at TLS level; expensive for frequent small messages. - HTTP/2: HPACK reduces header size but uses stateful compression; misordered updates can stall if proxies rewrite headers. - HTTP/3: QPACK designed for QUIC to reduce head‑of‑line issues for header compression, improving small-message efficiency.

- Server Push - HTTP/2 supports server push (push promises) to proactively send resources; in practice it’s rarely used due to cache/ordering complexity, proxies, and difficulty controlling client cache behavior. - HTTP/3 keeps push semantics but same practical limitations; for realtime you usually prefer explicit streaming or SSE/WebSocket push rather than push promises.

- Connection coalescing / reuse - HTTP/2: can reuse a single connection for multiple origins if TLS certs and authority match (connection coalescing), reducing connection overhead for many endpoints. - HTTP/3: similar coalescing benefits, plus faster connection establishment (0-RTT in QUIC), so ephemeral reconnects are cheaper — useful for mobile clients. - For SRE, fewer connections means lower resource usage (file descriptors, TCP buffers) and simpler load balancing, but also means one connection failure affects many streams (mitigate with graceful reconnection).

- Impact on long‑lived connections like SSE - HTTP/1.1 SSE works but consumes a whole connection per client; scaling requires many TCP connections. - HTTP/2 reduces per‑client connection count via multiplexed streams, enabling multiple SSE endpoints per connection and reducing memory/FD pressure. - On HTTP/2 over TCP, packet loss or congestion control interactions can still pause multiple SSEs (TCP HOL). HTTP/3 reduces that risk and improves tail latency for long‑lived streams. - Beware of intermediary proxies that may not keep idle HTTP/2/3 connections alive; you may need keepalives, shorter ping intervals, or application-level heartbeats.

When prefer HTTP/2/3 streaming over raw WebSockets- Prefer HTTP/2/3 when: - You want to keep using HTTP semantics (method/headers/status) and existing HTTP middleware, auth, and observability. - Traffic is mostly server → client (SSE‑style) or low‑frequency bidirectional messages. - You need many concurrent lightweight streams per client and want connection coalescing and TLS multiplexing benefits. - You want simpler ops with existing HTTP load balancers and CDN support (many CDNs now support HTTP/2/3 streaming).- Prefer WebSockets when: - You require true low‑latency, high‑frequency bidirectional binary communication (games, trading). - You need full-duplex message framing with predictable ordering semantics independent of HTTP flow control. - Your proxies/load balancers don’t handle HTTP/2/3 well or you need sticky TCP-based semantics.

Operational considerations (SRE lens)- Monitor connection counts, stream counts per connection, and QUIC metrics (RTT, loss) separately from TCP.- Configure keepalives, pings, and timeouts to survive idle periods and proxy timeouts.- Test behaviour through your whole path (CDN, reverse proxies, ingress controllers)—some intermediaries downgrade/terminate HTTP/2/3.- Watch resource usage: fewer connections reduces fds but increases per‑connection state; plan limits and autoscaling accordingly.

Summary: HTTP/2/3 make HTTP-based realtime streaming much more viable and efficient than HTTP/1.1 by enabling multiplexing, better header compression, and (with HTTP/3) reduced HOL. For many SRE use cases—especially many concurrent unidirectional streams and simpler HTTP ops—HTTP/2/3 streaming is preferable; for highly interactive, high-throughput bidirectional workloads, WebSockets remain the better fit.

Unlock Full Question Bank

Get access to hundreds of Real Time Data and Communication interview questions and detailed answers.

Join thousands of developers preparing for their dream job.