Planteamiento y contexto
La aplicación envía actualizaciones de alta frecuencia de cursores, posturas o vistas previas de arrastre, donde el estado más reciente importa más que cada actualización histórica. Explica cómo usar datagrams de WebTransport, gestionando la pérdida no ordenada, los presupuestos de tamaño, la contrapresión (backpressure), las reconexiones y los navegadores no compatibles. No te limites únicamente a comparar WebSocket con HTTP/3.
Qué evalúa el entrevistador
- Saber que los datagramas no garantizan la entrega ni el orden y no pueden transportar información crítica.
- Diseñar versiones de mensajes, tiempos de expiración, reglas de descarte y presupuestos de tráfico.
- Separar los datagramas de los flujos confiables y gestionar colas, congestión y reconexiones.
- Proporcionar HTTPS, detección de capacidades, mecanismos de respaldo (fallback) y observabilidad.
Preguntas de clarificación que debes hacer
- ¿Qué mensajes son estados transitorios reconstruibles y cuáles requieren persistencia confiable y ordenada?
- ¿Qué tamaño de datagrama, tasa de actualización, latencia objetivo y tasa de pérdida son aceptables?
- ¿Puede un cliente recuperarse a partir de una instantánea (snapshot) y de dónde obtiene el estado autoritativo tras una reconexión?
- ¿Admiten los navegadores y las redes WebTransport, HTTPS y HTTP/3? ¿Cuál es el mecanismo de respaldo (fallback)?
Estructura de respuesta en 30 segundos
Reservaría los datagramas para el estado actual descartable y colocaría las operaciones, los permisos y los resultados finales en un flujo confiable o en el almacenamiento del servidor. Cada actualización de estado llevaría una secuencia, una marca de tiempo y una versión del objeto; los receptores aplican solo las versiones más nuevas y descartan los datos obsoletos. Los emisores limitan el tamaño, la tasa y la longitud de la cola en lugar de almacenar en búfer indefinidamente. Una conexión comienza con una instantánea confiable, las reconexiones obtienen nuevamente el estado autoritativo y los fallos de compatibilidad recurren a un canal confiable existente.
Análisis detallado paso a paso
1. Establecer el límite de confiabilidad
Los cursores y las vistas previas son reconstruibles y se adaptan a los datagramas. Las operaciones sobre documentos, los cambios de permisos y los resultados de confirmación (commit) requieren una ruta confiable y ordenada. Compartir una misma conexión no hace que ambas semánticas de transporte sean intercambiables.
2. Diseñar mensajes descartables
Adjunta una secuencia monotónica, la hora de creación y una versión de sesión a cada objeto. Acepta solo versiones más nuevas; descarta los mensajes fuera de la ventana de frescura, correspondientes a objetos eliminados o anteriores a la versión actual. Un datagrama no debe contener un dato único que una instantánea no pueda restaurar.
3. Controlar el presupuesto y la recuperación
Limita el tamaño del mensaje, la tasa de envío y la longitud de la cola; cuando la cola esté cerca de su límite, fusiona (coalesce) el estado más nuevo para cada objeto. Después de reconectarse, obtén una instantánea a través del flujo confiable antes de aplicar nuevos datagramas para que el estado transitorio obsoleto no pueda sobrescribirla.
4. Compatibilidad y observabilidad
Establece la conexión solo en un contexto seguro y detecta las capacidades del navegador. Registra la tasa de descarte, la longitud de la cola, los fallos de envío, las reconexiones y el tiempo de reparación mediante instantáneas. Implementa un mecanismo de respaldo con WebSocket o sondeo (polling) cuando WebTransport no esté disponible, manteniendo el mismo protocolo de versiones de estado.
Respuesta modelo
Clasificaría los mensajes como estado transitorio reconstruible o información sin tolerancia a pérdidas: los cursores y las vistas previas de arrastre usan datagramas, mientras que las operaciones de documentos, los permisos y los resultados de confirmación usan un flujo confiable. Cada datagrama incluye una versión de objeto, secuencia y marca de tiempo; los receptores aceptan las versiones más nuevas y descartan las obsoletas, mientras que los emisores limitan el tamaño, la tasa y la cola, y fusionan actualizaciones. Al conectarse o reconectarse, una instantánea confiable establece la autoridad antes de que se reanuden los datagramas. HTTPS, la detección de capacidades, el respaldo mediante WebSocket o sondeo, y las métricas de pérdida, colas, reconexiones y tiempo de reparación completan el diseño.
Errores comunes
- Tratar los datagramas como una cola confiable y ordenada.
- Enviar permisos, pagos o información no reconstruible como datagramas.
- Omitir versiones y frescura, permitiendo que el estado antiguo sobrescriba el estado nuevo.
- Dejar que la cola de envío crezca sin límite durante situaciones de congestión.
- Reanudar el estado antiguo tras una reconexión sin obtener una instantánea autoritativa.
- Ignorar HTTPS, la detección del navegador y los mecanismos de respaldo.
Preguntas de seguimiento y respuestas
¿Qué haces cuando aumenta la pérdida?
Reduce la ventana de estado, disminuye la tasa de envío y fusiona las actualizaciones de cada objeto; mantén la información crítica en el flujo confiable. Reconsidera el uso de datagramas si el estado no se puede reconstruir a partir de una instantánea.
¿Cómo evitas que sobrescrituras fuera de orden alteren el estado?
Compara las versiones de los objetos o las secuencias monotónicas y acepta únicamente valores mayores. Avanza la época (epoch) de la sesión al reconectarte y rechaza los mensajes de sesiones anteriores.
¿Por qué mantener un flujo confiable?
Los datagramas no garantizan la llegada ni el orden, y son adecuados para estados donde «el nuevo valor reemplaza al valor anterior». Los registros, las instantáneas, los permisos y las confirmaciones finales requieren transporte confiable y persistencia.