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.

HardSystem Design

87 practiced

Design an end-to-end architecture for a real-time collaborative document editor (Google Docs style) which supports concurrent editing, offline edits, presence and cursor sync, and document version history. Address the choice between CRDT and OT, document sharding, persistence and compaction, broadcasting edits, user presence scaling, and the operational concerns for millions of documents.

Sample Answer

Requirements & constraints:- Real-time low-latency edits (milliseconds), offline edits sync, strong user experience for cursors/presence, global scale: millions of docs, millions of users, retention/version history, multi-region availability.

High-level architecture:- Clients (web/mobile) ↔ Edge Gateways (WS) ↔ Collaboration Service cluster (per-shard) ↔ Durable Storage (primary DB + append log) ↔ Background Services (compaction, history, search) ↔ Presence/Notification layer (Pub/Sub, push).

CRDT vs OT (recommendation):- Use CRDT (Conflict-free Replicated Data Types) for operational simplicity, offline-first support, and easier multi-master conflict resolution. CRDTs (sequence CRDTs like RGA/Logoot/WOOT or optimized variants like Yjs/Automerge with improvements) embed position identifiers so merges are deterministic without a central sequencer.- OT pros: less metadata overhead & proven in some systems; cons: requires a central transformation server or complex transformation matrices and is brittle for offline multi-branch sync. For a solutions architect aiming for robustness and offline-first capabilities, CRDTs are preferable.

Document sharding and routing:- Shard by document ID using consistent hashing. For hot documents, autoscale by pinning to a small group of collaboration nodes and employ leader election within shard for sequencing local broadcast (not for conflict resolution, only for ordering UI events).- For very large docs, horizontal split into logical chunks (e.g., 64KB ranges) — clients fetch relevant chunks and operations target chunk IDs. Maintain a global document manifest mapping chunk ranges.

Real-time broadcasting & presence:- Use WebSocket/HTTP2 streams at edge gateways. Collaboration nodes subscribe to per-document Pub/Sub channels (e.g., Kafka/Redis streams/GCP PubSub) for cross-region fanout. Local edits get applied locally (CRDT merge), broadcast as ops to channel; peers receive and merge.- Presence/cursor: separate lightweight channel maintained in-memory with TTL; use Redis Cluster or a specialized presence store (e.g., scaled actor system) for fast reads. Broadcast presence deltas at low frequency; use interest-based filtering to limit churn.

Persistence, version history, and compaction:- Persist operations as append-only log (per document) in durable store (object store or append DB). Periodically snapshot the CRDT state into stable checkpoints (e.g., every N ops or time window) to speed recovery. Compaction: background job compacts logs into snapshots + retained deltas for incremental history; keep checkpoints for branching and version history. Store full immutable versions for user-visible history (tagged snapshots).- Use content-addressed storage for blobs and delta compression to save space.

Scaling & operational concerns:- Lease-based leadership per shard to coordinate broadcasts and background compaction tasks; avoid single points of failure. Autoscale collaboration nodes and edge gateways based on active connections and ops/sec.- Multi-region deployment: place gateways near clients; replicate durable storage with region-aware routing. Use causal delivery guarantees within region and eventual cross-region convergence (CRDT ensures correctness).- Monitoring/observability: metrics for ops/sec, queue lag, snapshot latency, memory (CRDT growth), and presence churn. Alert on hot-doc hotspots and backpressure.- Cost/GC management: CRDT metadata can grow — implement periodic tombstone pruning (safe via global checkpoint) and opportunistic merging. Enforce doc retention policies and archive cold docs to cheaper storage; cold restore rehydrates CRDT from snapshot+ops.- Security & consistency: encrypt in transit/at rest, per-doc access control enforced at gateway and collaboration nodes, and audit logging for history.

Trade-offs:- CRDT increases metadata and storage but simplifies offline and multi-master sync. OT may save bandwidth but increases server complexity and offline merge complexity.- Chunking adds complexity but enables very large documents and parallel edits.- Strong real-time ordering isn’t necessary for correctness with CRDT; only for UX (cursor stability) — achieve via local heuristics + optional sequence numbers from leader.

Implementation roadmap (phased):1. Core CRDT-based engine + single-region collaboration service, WS gateway.2. Persistence (append log + snapshots) and background compaction.3. Presence service and cursor sync.4. Sharding, chunking, autoscaling, and cross-region replication.5. Optimizations: tombstone pruning, delta compression, archival, enterprise features (RBAC, audit, retention).

This design delivers low-latency real-time collaboration, robust offline support, scalable presence, and manageable operational overhead for millions of documents.

EasyTechnical

98 practiced

Explain the difference between pub/sub and point-to-point messaging models in real-time architectures. As a Solutions Architect, when would you specify a brokered pub/sub model vs direct peer-to-peer connections? Discuss the scalability and operational implications of choosing a brokered approach.

HardTechnical

53 practiced

How would you preserve message ordering guarantees while partitioning topics and scaling for throughput? Propose designs that allow per-key FIFO ordering, discuss the role of sequence numbers, key-based partitioning, how to handle partition rebalancing and partition migration, and techniques to mitigate hot-key effects without breaking ordering.

Sample Answer

High-level goal: guarantee per-key FIFO while partitioning for throughput. I’ll present two practical designs (partition-affinity and sequencer-merging), then cover sequence numbers, rebalancing/migration, and hot-key mitigation with their trade-offs.

Design A — Key-affinity partitions (simple, common)- Hash each message’s key to a partition (consistent hashing + virtual nodes to balance).- Ensure all messages for a key go to the same partition => natural per-key FIFO.- Make producers write with idempotence and retries; brokers assign offsets per-partition.- Consumers use sticky/cooperative rebalancing so ownership moves cleanly.

Pros: low latency, simple. Cons: hot keys map to a single partition (scales poorly).

Design B — Sharded-ordered streams with sequencer + merge (scalable hot-key handling)- For hot keys, split into ordered sub-shards (key:K#0..K#N). A per-key sequencer (lightweight service or leader for the key) assigns monotonically increasing sequence numbers across sub-shards.- Producers either route to sequencer (adds seq) then to sharded partitions, or use deterministic partitioning with producer-side round-robin + sequencer to ensure global ordering token.- Consumers merge messages for a key by sequence number (stream merge), preserving FIFO.

Sequence numbers — role and properties- Monotonic per-key sequence numbers are the canonical ordering token.- Must be durable and idempotent: attach (key, seq, producer-id).- Use sequence numbers for deduplication, out-of-order detection, and merging across shards.- For high availability, use epoched sequences (seq + epoch/leader-id) to detect sequencer failover.

Partition rebalancing & migration- Prefer cooperative/sticky rebalancing to avoid abrupt ownership changes.- When migrating a partition: quiesce writes (short pause) or perform dual-write to old+new partition while marking a migration window. Consumers read both and use sequence numbers/offsets to reconcile.- Use a handoff protocol: 1) new owner becomes ready, 2) producers switch to new owner (or metadata updates), 3) old owner drains outstanding messages, 4) final cutover. Track highest committed sequence per-key to avoid loss.- For stateful consumers (processors), checkpoint per-key seq offsets; on reassign, resume from checkpoint to maintain ordering.

Hot-key mitigation (without breaking ordering)- Key splitting + sequencer-merge (as above) lets throughput scale horizontally while keeping global order via seq.- Rate-limit or backpressure producers for a hot key; use adaptive throttling to avoid head-of-line blocking.- If strict strict global per-key ordering is unnecessary, provide “session ordering” or “bounded reordering” (allow reordering within window) to improve throughput.- Use virtual nodes plus rehashing to spread moderate hot keys across multiple physical partitions; coordinate with sequence numbers or lightweight sequencer to restore ordering.

Trade-offs- A: minimal overhead, limited scale for hot keys.- B: higher complexity (sequencer, merge, epoch management) but scales hot keys; increases latency and operational burden.- Rebalancing/migration: aim for short, orchestrated handoffs to avoid duplicates/holes—use sequence numbers and idempotent writes to ensure correctness.

Recommended for clients- Start with key-affinity partitioning + consistent hashing and sticky rebalances.- Add sequencer-based sharding for identified hot keys only (gradual adoption).- Enforce idempotent producer writes, attach (key, seq, epoch), and use consumer-side merge with checkpoints to guarantee per-key FIFO while scaling throughput.

EasyTechnical

44 practiced

As a Solutions Architect, explain the differences between WebSockets, Server-Sent Events (SSE), long polling, and regular polling. For each transport describe: bidirectional vs unidirectional behavior, typical latency and connection overhead, proxy and firewall impacts, browser and mobile support, battery/data implications, and example use-cases where you'd recommend each approach.

Sample Answer

Situation overview: As a Solutions Architect choosing a realtime transport, you balance directionality, latency, overhead, reliability across proxies, client support, and cost (battery/data). Below is a concise comparison and recommended use cases.

WebSockets- Direction: Bidirectional full-duplex (client↔server).- Latency/overhead: Very low latency after handshake; single persistent TCP connection minimizes per-message overhead.- Proxy/firewall impacts: Some corporate proxies may block or mishandle; falls back via WebSocket-over-HTTP (ws/wss) but can be blocked. TLS (wss) mitigates inspection issues.- Browser/mobile support: Excellent across modern browsers and mobile webviews; native SDKs support on mobile.- Battery/data: Efficient for frequent two-way messages; idle connections consume keepalive pings.- Use-cases: Chat, multiplayer games, collaborative editors, financial tickers requiring low latency bi-directional comms.

Server-Sent Events (SSE)- Direction: Unidirectional (server→client) over HTTP/1.1.- Latency/overhead: Low latency for server pushes; lighter handshake than WebSocket; reconnects on drop.- Proxy/firewall impacts: Generally friendly to proxies (standard HTTP streaming); intermediary timeouts can close long-lived streams.- Browser/mobile support: Good in modern browsers (no IE); mobile webviews vary; native mobile apps need wrappers.- Battery/data: Efficient for frequent server pushes; client cannot send messages except via separate HTTP calls.- Use-cases: Live feeds, notifications, logs, one-way streaming where client-originated messages are infrequent.

Long polling- Direction: Emulates server→client pushes via repeated HTTP requests; client polls but server holds request until data available.- Latency/overhead: Moderate latency (depends on server hold time); higher overhead due to repeated HTTP request/response cycles.- Proxy/firewall impacts: Very friendly (standard HTTP); less risk of blocking.- Browser/mobile support: Universal.- Battery/data: Higher cost than WebSocket/SSE because of repeated HTTP headers; okay for moderate update rates.- Use-cases: Compatibility scenarios, older clients, where server push needed but WebSocket/SSE unavailable.

Regular polling- Direction: Unidirectional (client→server polling for updates).- Latency/overhead: Highest latency or high overhead depending on poll frequency; simple to implement.- Proxy/firewall impacts: No issues—plain HTTP.- Browser/mobile support: Universal.- Battery/data: Worst for battery/data at high frequencies.- Use-cases: Low-frequency metrics, coarse refresh UIs, fallback when real-time not required.

Trade-offs summary:- Use WebSockets when you need low-latency bidirectional comms.- Use SSE for scalable, simple server→client streams.- Use long polling where push needed but real-time transports blocked.- Use regular polling for simple, low-rate scenarios or maximum compatibility.

Implementation notes: prefer TLS (wss/https) for security; include heartbeat/reconnect logic and exponential backoff; design for proxy timeouts (periodic re-establish or keepalives).

HardTechnical

62 practiced

As a Solutions Architect you learn engineering cannot meet a contracted SLO for real-time delivery promised in a proposal. Describe your immediate remediation steps, client communication plan, short-term technical workarounds you might propose, and the long-term roadmap to get back to SLO while protecting company reputation and client relationship.

Sample Answer

Situation: During a proposal handoff for a real-time telemetry product I owned as Solutions Architect, engineering surfaced that current architecture and latency measurements could not reliably meet the contracted SLO for end-to-end delivery under expected peak load.

Task: I needed to protect the client relationship and company reputation, deliver an immediate remediation plan, propose safe short-term workarounds, and own a credible long-term roadmap to meet the SLO.

Action:Immediate remediation (first 24–48 hours)- Convened a triage with Eng, SRE, QA, Product, and Legal to confirm the gap, quantify expected SLA delta, and identify quick risk mitigations.- Created a one-page impact summary: what metrics miss the SLO, affected clients/functions, and estimated duration.- Stopped any further commitments in sales collateral until client communication plan approved.

Client communication plan (within 48 hours)- Proactively notified the client lead with a factual, non-blaming message: what we discovered, the measured impact, and that we’re treating it as top priority.- Promised a timeline for a technical remediation proposal (48–72 hours) and weekly status updates.- Offered a named technical liaison and a phone/virtual war-room for questions; involved Sales and Legal to align contractual language and next steps.

Short-term technical workarounds (days–weeks)- Implemented prioritized mitigations that preserve functionality: traffic shaping to reduce burst load; best-effort quality tiers (e.g., degrade non-critical telemetry); client-side batching and compression to lower per-event overhead.- Deployed caching at ingress and lightweight ACKs to reduce tail latency.- Turned on extended monitoring and alerting with dashboards shared to the client so they can see progress.

Long-term roadmap (weeks–months)- Root cause analysis, capacity and latency modeling, and architecture redesign where needed (e.g., add partitioning, stream-processing scaling, or switch to lower-latency transport).- Phased delivery plan with acceptance gates: lab proof-of-concept → canary in production → full rollout. Include load testing at 2x expected peak.- SRE runbooks, autoscaling tuning, SLA observability, and agreed SLO error budget policies.- Contractually, propose an amended transitional SLO with service credits or discounted support until full compliance, negotiated with Legal and Sales to protect revenue and trust.

Result / Learning:- This approach buys time, demonstrates transparency, and reduces client risk while engineering fixes the root cause. I emphasize measurable milestones, shared visibility, and contractual remedies to repair trust and ensure the long-term architecture sustainably meets the promised SLO.

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.