Prompt and context
The application sends high-frequency cursor, pose, or drag-preview updates where the newest state matters more than every historical update. Explain how to use WebTransport datagrams, handling unordered loss, size budgets, backpressure, reconnects, and unsupported browsers. Do not only compare WebSocket with HTTP/3.
What the interviewer evaluates
- Knowing that datagrams do not guarantee delivery or ordering and cannot carry critical facts.
- Designing message versions, expiry, discard rules, and traffic budgets.
- Separating datagrams from reliable streams and handling queues, congestion, and reconnects.
- Providing HTTPS, capability detection, fallback, and observability.
Clarifying questions to ask
- Which messages are reconstructible transient state, and which require reliable ordered persistence?
- What datagram size, update rate, target latency, and loss rate are acceptable?
- Can a client recover from a snapshot, and where does a reconnect obtain authoritative state?
- Do browsers and networks support WebTransport, HTTPS, and HTTP/3? What is the fallback?
30-second answer framework
I would reserve datagrams for discardable current state and put operations, permissions, and final results on a reliable stream or server store. Each state update would carry a sequence, timestamp, and object version; receivers apply only newer versions and discard stale data. Senders cap size, rate, and queue length rather than buffering forever. A connection starts with a reliable snapshot, reconnects fetch authoritative state again, and capability failure falls back to an existing reliable channel.
Step-by-step deep dive
1. Set the reliability boundary
Cursors and previews are reconstructible and fit datagrams. Document operations, permission changes, and commit results require a reliable ordered path. Sharing one connection does not make the two transport semantics interchangeable.
2. Design discardable messages
Attach a monotonic sequence, creation time, and session version to each object. Accept only newer versions; discard messages outside the freshness window, for deleted objects, or behind the current version. A datagram should not contain a unique fact that a snapshot cannot restore.
3. Control budget and recovery
Cap message size, send rate, and queue length; when the queue is near its limit, coalesce the newest state for each object. After reconnecting, fetch a snapshot over the reliable stream before applying new datagrams so stale transient state cannot overwrite it.
4. Compatibility and observability
Establish the connection only in a secure context and detect browser capability. Record discard rate, queue length, send failures, reconnects, and snapshot-repair time. Fall back to WebSocket or polling when WebTransport is unavailable while keeping the same state-version protocol.
Model answer
I would classify messages as reconstructible transient state or non-lossy facts: cursors and drag previews use datagrams, while document operations, permissions, and commit results use a reliable stream. Every datagram carries an object version, sequence, and timestamp; receivers accept newer versions and discard stale ones, while senders cap size, rate, and queue and coalesce updates. On connect or reconnect, a reliable snapshot establishes authority before datagrams resume. HTTPS, capability detection, WebSocket or polling fallback, and metrics for loss, queues, reconnects, and repair time complete the design.
Common mistakes
- Treating datagrams as a reliable ordered queue.
- Sending permissions, payments, or non-reconstructible facts as datagrams.
- Omitting versions and freshness, allowing old state to overwrite new state.
- Letting the send queue grow without bound under congestion.
- Resuming old state after reconnect without fetching an authoritative snapshot.
- Ignoring HTTPS, browser detection, and fallback.
Follow-up questions and responses
What do you do when loss increases?
Shorten the state window, lower the send rate, and coalesce updates for each object; keep critical facts on the reliable stream. Reconsider datagrams if state cannot be rebuilt from a snapshot.
How do you prevent out-of-order overwrites?
Compare object versions or monotonic sequences and accept only larger values. Advance the session epoch on reconnect and reject messages from older sessions.
Why keep a reliable stream?
Datagrams do not guarantee arrival or ordering and suit “new value replaces old value” state. Logs, snapshots, permissions, and final confirmations require reliable transport and persistence.