Adobe Real-Time Collaboration And WebSockets

What's being tested

Interviewers are probing your ability to design and reason about low-latency, stateful real-time systems that use persistent bidirectional connections for collaborative experiences. Expect questions on correct consistency models (OT vs CRDT), session/handoff semantics for disconnected clients, and practical scaling (load, fan‑out, state sharding). Adobe cares because collaboration features must be fast, robust, and integrable with existing backend services without breaking UX or data integrity.

Core knowledge

WebSocket basics: persistent TCP connection with full-duplex frames; handshake over HTTP/HTTPS; keepalive/ping-pong for liveness and NAT traversal considerations.
Connection resource math: estimate memory/FDs per connection (e.g., 1–10 KB server-side state, one file descriptor), so N connections ≈ N * per-conn memory + overhead; use this to size instances.
Transport vs delivery semantics: WebSocket provides ordered delivery per TCP connection but not global ordering across connections; implement sequencing/causal metadata for multi-client ordering.
Consistency models: Operational Transformation (OT) provides intention-preserving transforms; Conflict-free Replicated Data Types (CRDTs) provide merge-by-design without central transforms — pick based on complexity of operations and offline support.
State partitioning and sharding: shard by document ID (or room) with consistent hashing to keep affinity; hot documents require dynamic re-sharding or replication to avoid a single-node hotspot.
Fan-out strategies: push via single leader per shard for broadcasts, or use a pub/sub layer (Redis, Kafka, or a specialized event mesh). For large fan-out, prefer multicast via dedicated push layer rather than iterating sockets in app code.
Durability and ordering: persist a canonical operation log (append-only) for replay and recovery; sequence numbers or vector clocks help with idempotency and detecting missing operations.
Offline clients and reconciliation: store per-client oplogs or use tombstoning; reconciliation must be bounded (garbage-collect old ops after checkpoint snapshots).
Scaling connection brokers: separate the gateway (terminates WebSocket) from the stateful engine; gateways forward frames to real-time processors via low-latency RPC (gRPC, binary protocols) or pub/sub.
Backpressure and flow control: detect slow consumers and apply strategies: drop/compact updates, buffer with bounded queues, or prioritize control messages; measure p99 tail latency to avoid head-of-line blocking.
Security and auth: short-lived tokens (JWT or signed lease) for connection auth; re-auth on reconnect; always run over wss and validate origin if necessary.
Monitoring and SLOs: track metrics like connections-per-host, messages/sec, average fan-out, p50/p99 end-to-end latency, operation success rate, and state divergence incidents.

Worked example — "Design a real-time collaborative editor using WebSockets (supporting concurrent edits and offline clients)"

Start by clarifying scope: max concurrent users per document, offline tolerance, and correctness expectation (eventual vs strong consistency). Outline three pillars: client protocol, server architecture, and conflict resolution. For client protocol, propose an op-based model where clients send edits with local sequence numbers and receive acks plus server sequence. For server architecture, design a shard-per-document model: WebSocket gateways accept connections, forward events to a per-document leader process that sequences ops and publishes to a durable append-only log for persistence and recovery. For conflict resolution, choose CRDT if offline edits and simple merge semantics are primary; choose OT if you must preserve user intent and support complex transforms. A key tradeoff: OT gives higher UX fidelity but increases server complexity and testing; CRDT simplifies merging but can bloat state and require more metadata. Close by saying: "If I had more time, I'd sketch the exact op schema, simulate edge cases (network partitions), and propose a migration path for hot documents (replication/leader failover)."

A second angle — "Scale WebSocket connections for presence service with millions of users"

Here the same building blocks apply but constraints shift to connection density and lightweight state. Frame the problem by asking: are presence updates coarse (online/offline) or high-frequency (cursor movement)? Structure response around gateway scaling, aggregated presence, and aggregation latency. Use stateless gateways that forward presence events to a highly scalable pub/sub (Kafka or a managed stream) and maintain in-memory presence in sharded stores (Redis Cluster) for quick reads. For fan-out, prefer delta aggregation (publish only changes) and push to users via edge gateways colocated to reduce cross‑datacenter hops. Explicitly state tradeoffs: eventual consistency is acceptable for presence; strict ordering is not. Quantify: with 10M users sending a presence heartbeat every 30s, that's ~333k msgs/sec — size your ingestion and partitioning accordingly.

Common pitfalls

Pitfall: Designing with a single global sequencer — it simplifies ordering but becomes a scalability and availability bottleneck; prefer per-document leaders with consensus/failover.

Pitfall: Assuming WebSocket frames equal business-delivery — you must add sequence numbers, ack/nack, and replay logic for reconnects, otherwise clients will experience missed or duplicated ops.

Pitfall: Over-engineering conflict resolution in first pass — don't implement full OT transforms for every operation without validating user-visible benefit; start with CRDTs or server-side simple transforms and iterate based on correctness incidents.

Connections

Interviewers may pivot to adjacent topics like distributed consensus (leader election, Raft for leader failover), CDN/edge design for reducing latency, or mobile offline sync patterns. Be ready to connect your design to operational concerns: deployment, observability, and cost tradeoffs.