Prompt and context
A real-time collaboration app must reliably deliver document operations while sending cursor positions and heartbeats that may be dropped. The team chose WebTransport but has not defined close behavior, network changes, reconnect, backpressure, or cleanup. Design the lifecycle and explain the boundaries among reliable streams, unreliable datagrams, and an HTTP/3 connection.
The W3C WebTransport API exposes reliable streams and unreliable datagrams; RFC 9297 defines HTTP datagrams. A strong answer separates the application session from the transport and does not treat close() as proof that every business message was delivered.
What the interviewer is testing
- Distinguishing session close, stream close, datagram loss, and network failure.
- Designing reconnect, session recovery, sequence numbers, idempotency, and snapshots.
- Handling stream backpressure, datagram limits, slow clients, and resource caps.
- Defining close codes, reasons, timeouts, and observability.
- Setting explicit browser, proxy, HTTP/3, and fallback boundaries.
Clarifying questions
- Which messages must be reliable and ordered, and which may be dropped or reduced to the newest value?
- Can a session recover across network changes? What recovery time and operation history are acceptable?
- What limits apply to concurrent sessions, streams, and datagram rate per user?
- Is close user initiated, maintenance, authentication expiry, overload, or a protocol error?
- Do browsers and proxies support WebTransport over HTTP/3, and what is the explicit fallback?
30-second answer
Separate the application session ID from one WebTransport connection. Send reliable operations over streams with sequence numbers and idempotency keys; send cursors and heartbeats as lossy datagrams. On failure, retain server-side session state briefly; reconnect with exponential backoff and the last confirmed sequence, then recover from a snapshot plus deltas. For graceful close, stop new work, drain reliable streams, send an application completion marker, close with a code, and enforce a hard timeout. Bound every buffer and resource.
Deep-dive answer
1. Establish application and transport sessions
An application session ID represents the user's logical membership in a collaboration room; a WebTransport instance is one network connection. After the handshake, validate origin, authentication, tenant, and room permission, create a connection ID, and map it to the application session. Reconnect creates a new connection ID and never grants another user's session.
Store the last confirmed operation sequence, snapshot version, subscriptions, and expiry. After a disconnect, mark the application state suspended for a short TTL before releasing it.
2. Choose streams or datagrams per message
Document operations, permission changes, and acknowledgements use reliable streams with explicit framing, version, sequence number, and idempotency key. Cursors, live metrics, and heartbeats use datagrams, with receivers discarding stale timestamps or versions. Never put a must-deliver business event in a datagram.
Datagrams provide no delivery, ordering, or retransmission guarantee and have path and implementation size limits. Measure loss and latency, reduce frequency, or send only the newest state. Reliable streams use WritableStream backpressure instead of unbounded memory queues.
3. Handle backpressure and slow clients
Set a sending window, pending-ack limit, and maximum frame size per reliable stream. When a write remains pending, pause producers; on timeout, disconnect or reduce non-critical subscriptions. Use token buckets and per-session budgets for datagrams; dropping an old cursor is preferable to blocking document operations.
Also cap session count, stream count, concurrent decoding, and total memory. Aggregate metrics by tenant so one slow client cannot consume the event loop.
4. Design disconnect and recovery
The client assigns local sequence numbers and idempotency keys to reliable operations and advances a checkpoint after acknowledgement. A reconnect handshake carries session ID, last confirmed sequence, and capabilities. The server verifies session ownership and returns a snapshot, deltas, or an unrecoverable error.
Pause new side effects during recovery so old and new connections cannot submit concurrently. Use an epoch to invalidate writes from the old connection and reopen producers only after recovery completes.
5. Design graceful shutdown
During maintenance, broadcast draining, reject new sessions, and stop non-critical datagrams. Let reliable streams finish their current frame and send an application completion marker, then close the session after a bounded wait. Browser close() communicates session closure and close information; it is not a business acknowledgement.
Classify close codes for normal exit, authentication expiry, overload, protocol error, and maintenance. Keep reasons short and non-sensitive. At the hard timeout, release resources immediately and record unfinished operations.
6. Recheck authentication and network changes
Each new or recovered connection revalidates credentials, origin, tenant, and room permission. Do not recover on a session ID alone. A network change may alter the address; application recovery uses a new connection, while the epoch prevents the old path from writing.
If WebTransport or HTTP/3 is unavailable, negotiate a fallback explicitly and restate reliability, latency, and security differences. Do not apply WebSocket close semantics to datagrams.
7. Observe and exercise failure modes
Record connection creation, handshake failures, close code and reason, stream backpressure, dropped datagrams, reconnect count, recovery duration, and unacknowledged operations. Do not log tokens or sensitive document content. Segment metrics by client, network type, and tenant.
Exercise maintenance, mobile network changes, HTTP/3 proxy blocking, slow clients, datagram bursts, and duplicate reconnects. Acceptance criteria include no duplicate side effects, explicit recovery limits, expired-session cleanup, and bounded close latency.
Model answer
I would separate the application session from the WebTransport connection. Reliable document operations use streams with sequence numbers and idempotency keys; cursors and heartbeats use lossy datagrams. The client stores a checkpoint and reconnects with session ID and last confirmed sequence. The server verifies user and tenant, restores from snapshot plus deltas, and uses an epoch to invalidate old writes.
Graceful shutdown enters draining, stops new messages and non-critical datagrams, drains reliable streams, sends an application completion marker, then closes with a code and hard timeout. Bound sessions, streams, buffers, and reconnects; monitor loss, backpressure, close reasons, and recovery time. Negotiate any fallback explicitly.
Common mistakes
- Treating datagrams as reliable messages or
close()as business acknowledgement. - Creating a new connection after failure without checkpoint, epoch, or idempotency key.
- Buffering slow-client data forever and exhausting memory or the event loop.
- Recovering by session ID without revalidating user, tenant, origin, and permission.
- Omitting draining, a hard timeout, or unfinished-operation audit during close.
- Ignoring HTTP/3 blocking, browser support, and proxy behavior.
- Logging complete tokens, document content, or sensitive close reasons.
Follow-up questions and answers
What belongs in datagrams?
Loss-tolerant, short-lived values such as cursors, temporary pose, and high-frequency heartbeats. Business operations that must arrive use reliable streams.
How do you prevent duplicate operations after reconnect?
Assign idempotency keys and sequence numbers, deduplicate by session and epoch on the server, and advance the checkpoint only after acknowledgement.
How should maintenance shutdown work?
Stop new sessions and broadcast draining, stop non-critical datagrams, drain reliable streams, send a completion marker, then close normally. Force cleanup at the hard timeout.
What happens when the session TTL expires?
Return an unrecoverable error and require reauthentication and rejoining. An old session ID must not extend permission.
What if datagrams are too large or loss is high?
Cap size and rate, compress or coalesce state, and retain only the newest value. A business event cannot depend on an unreliable datagram.
How do you prove a fallback preserves semantics?
Document reliability, ordering, recovery, and authentication differences per protocol. Test disconnects, proxy blocking, slow clients, and duplicate reconnects while measuring duplicate side effects.