Prompt and scope
A collaborative whiteboard carries cursors, batched edits, and file chunks. Compare WebTransport with WebSocket and explain how delivery guarantees, ordering, congestion, browser support, and operations drive the choice.
WebSocket offers a mature bidirectional message channel. WebTransport uses HTTP/3 and exposes reliable unidirectional or bidirectional streams plus lossy datagrams. The question tests matching transport semantics to system constraints, not repeating that HTTP/3 is faster.
What the interviewer evaluates
Look for a split between data that must arrive and data that may expire; understanding of ordering, backpressure, congestion, and closure; and an honest assessment of HTTP/3 servers, certificates, proxies, browser support, fallback, and observability.
30-second answer framework
“I would classify the data first: edits and file chunks use reliable, backpressured bidirectional streams; cursor positions can use datagrams because stale positions have no value. If target browsers, gateways, or servers do not reliably support WebTransport, I would start with WebSocket and retain capability-detected fallback. Both paths need authentication, quotas, heartbeats, reconnects, and metrics. I would decide from end-to-end loss, latency, reconnect, and operating-cost data.”
Step-by-step deep answer
Step 1: Define a delivery contract for each message
Edits need reliable delivery and ordering, usually with an operation ID for deduplication. File chunks need reliable streams, checksums, and resumable offsets. Cursor and drag-preview state can keep only the newest value and tolerate loss or reordering.
Step 2: Understand the WebSocket boundary
WebSocket has a simple, mature message model for one reliable bidirectional channel. The application still defines message types, backpressure, heartbeats, reconnects, broadcast, and large-message framing. A large message can complicate scheduling when every payload shares one channel.
Step 3: Understand WebTransport capabilities
WebTransport combines reliable unidirectional or bidirectional streams with unreliable datagrams. Streams carry ordered bytes; datagrams support low-latency updates that may be lost. Implementations must respect stream readiness, closure, and errors instead of assuming datagrams arrive.
Step 4: Give datagrams expiry and deduplication
Include an entity ID, sequence, or timestamp in each datagram. The receiver discards stale state rather than treating loss as a business failure. Keep only the latest cursor per user; send analytics or edit acknowledgements over a reliable stream.
Step 5: Handle stream backpressure and recovery
Wait for writable readiness and cap per-session queues. Pause low-priority updates or isolate an abusive client when the cap is exceeded. Checksum file chunks and persist offsets; after reconnect, continue from the last acknowledged chunk instead of replaying the whole file.
Step 6: Evaluate deployment and compatibility
WebTransport requires a compatible HTTP/3 server and certificate setup, plus proxy, firewall, and load-balancer validation. Test browser support, connection failures, HTTP/3 downgrade, and cross-region networks before rollout. Fall back to WebSocket or HTTP while preserving the same business semantics.
Step 7: Design authentication and resource isolation
Authenticate the session and origin at connection setup. Enforce per-user and per-tenant limits on connections, streams, datagram rate, and bytes. A client-declared stream priority is not authorization; file writes still require permission, checksums, and audit records.
Step 8: Decide with end-to-end metrics
Record send and arrival times, reconnects, stream errors, estimated datagram loss, queue length, CPU, and bandwidth by message type. Compare both transports and fallback under real networks, mobile handoffs, proxies, and concurrency.
Trade-offs and boundaries
One channel versus multiple semantics
One reliable WebSocket channel is easier to maintain. WebTransport can separate reliable streams from low-latency datagrams, but increases protocol, testing, and operations complexity. Take that cost only when the product needs both semantics.
Latency versus recoverability
Datagrams reduce waiting but require the business to accept loss and expiry. Critical state belongs on reliable streams with operation IDs, checkpoints, and replay protection.
New-protocol benefit versus deployment risk
HTTP/3 capability does not remove failures caused by unsupported browsers or network devices. Validate connection and fallback rates with a small rollout before expanding coverage.
Failure drills and evolution
HTTP/3 is unavailable on an enterprise network
Simulate proxy blocking or handshake failure. Confirm fast WebSocket fallback, no duplicate or lost critical edits, and an actionable failure metric.
Cursor updates build up
Cap datagram rate and create a slow network. Verify stale cursors are dropped while edit operations remain reliable.
A file stream is interrupted
Reconnect after interruption and verify chunk checksums, offset recovery, and renewed authorization. A client must not overwrite arbitrary offsets.
Common mistakes and follow-ups
Mistake 1: Assuming WebTransport is always faster
Ask for connection success, handshake time, and fallback rate on the target network.
Mistake 2: Sending critical edits as datagrams
Ask how loss, reordering, and duplication are handled; the answer should move edits to reliable streams with operation IDs.
Mistake 3: Discussing only browser APIs
Ask how HTTP/3 servers, load balancers, certificates, proxies, and observability are deployed.
Mistake 4: Omitting backpressure and quotas
Ask how a slow client is isolated and how per-tenant stream and byte limits are enforced.
Mistake 5: Creating a second business protocol for fallback
Ask how WebSocket and WebTransport preserve the same message contract and idempotency semantics.
Extended follow-ups and reference answers
Why separate cursor and edit traffic?
Cursors are transient and quickly stale, so loss is acceptable for lower latency. Edits must be reliable, ordered, and recoverable, so they belong on reliable streams.
What if WebTransport is unavailable?
Probe capability, then fall back to WebSocket or HTTP while preserving authentication, message IDs, reconnect, and business acknowledgements.
How do you prove the choice works?
Compare latency, estimated loss, reconnects, queues, CPU, bandwidth, and fallback in real-network cohorts, and verify critical operations are neither lost nor duplicated.