Prompt y contexto
Esta pregunta evalúa si usted puede transformar una optimización de latencia a nivel de transporte en un límite claro de seguridad de negocio. Los early data de TLS 1.3 pueden enviarse antes de que una conexión se establezca por completo, y el RFC 8470 advierte explícitamente sobre el riesgo de repetición (replay). Por lo tanto, la seguridad de la solicitud no puede decidirse únicamente a partir del nombre del método HTTP. Cubra clases de solicitudes, transiciones de estado, idempotencia, cachés y proxies, reintentos de clientes, monitoreo y fallback.
Qué evalúa el entrevistador
- Si usted distingue entre lecturas repetidas inofensivas y efectos secundarios repetidos.
- Si restringe early data a un conjunto seguro explícito y proporciona a las solicitudes dudosas una ruta de rechazo explicable.
- Si 425, las claves de idempotencia, la desduplicación y el backoff de reintentos funcionan de manera coordinada.
- Si puede explicar cadenas de proxies, logs, métricas, rollback y controles de despliegue gradual.
Preguntas de clarificación que conviene hacer primero
Confirme qué solicitudes pueden transportar early data, dónde termina TLS y si hay proxies o reintentos de mensajes después del edge. ¿Qué operaciones modifican saldos, inventario, órdenes, permisos o notificaciones? ¿El negocio ya cuenta con claves de idempotencia, una tabla de estados de solicitud y restricciones únicas? ¿Los clientes, SDKs y gateways entienden 425? ¿Quién reintenta, cuántas veces y con qué backoff exponencial y jitter? Si el almacenamiento de desduplicación no está disponible, ¿debe el servicio rechazar, recurrir a un handshake completo o continuar con el tráfico de solo lectura?
Estructura para una respuesta de 30 segundos
Excluiría por defecto de early data las solicitudes con efectos secundarios o cuya idempotencia no se pueda demostrar. El edge detecta early data y pasa una señal protegida a la aplicación; las lecturas seguras pueden continuar, mientras que las órdenes, cobros y cambios de permisos devuelven 425 o requieren un handshake completo. Para las escrituras que verdaderamente necesitan baja latencia, el cliente proporciona una clave de idempotencia y el servidor utiliza una restricción única y un estado de resultado de corta duración para persistir "processing" y "completed". Los clientes reintentan únicamente las respuestas que son explícitamente reintentables, con backoff exponencial acotado y jitter. Despliegue gradualmente y monitoree la ejecución duplicada, 425, el volumen de reintentos y las anomalías de negocio.
Análisis detallado paso a paso
1. Definir el límite de confianza para early data
Detecte early data en la capa de terminación de TLS y pásela a través de una señal interna protegida; un cliente público no debe poder falsificar un marcador de "solicitud segura". Defina si los proxies, cachés y llamadas de servicio a servicio pueden copiar o retrasar la solicitud. Trate por defecto una señal ausente o una ruta incierta como de alto riesgo.
2. Clasificar por efecto secundario de negocio
Las lecturas sin estado cuyo resultado repetido no modifica los recursos son más fáciles de aceptar. Crear órdenes, cobrar, decrementar inventario, cambiar permisos, enviar mensajes y llamar a sistemas externos son sensibles a repeticiones. Incluso PUT o DELETE deben verificarse frente a la implementación real; POST no es automáticamente no idempotente. El modelo de estados de negocio y las restricciones únicas determinan la garantía.
3. Diseñar 425 y el fallback a handshake completo
Devuelva 425 Too Early para las rutas que no permitan early data y documente cómo el cliente completa un handshake completo antes de reenviar. Un gateway no debe reintentar 425 infinitamente. Registre si la solicitud original pudo haber llegado a la aplicación para que el edge y el cliente no reintenten ambos y amplifiquen la carga. Cuando se desconoce la capacidad del cliente, una falla explícita es más segura que una ejecución silenciosa.
4. Usar claves de idempotencia y una máquina de estados
Vincule una clave de idempotencia al tenant, al tipo de operación y al digest de los parámetros de la solicitud. Persista los estados de procesamiento, éxito y fallo detrás de una restricción única. Una solicitud concurrente adquiere la clave; las demás leen el estado o esperan durante un tiempo acotado, mientras que una discrepancia de parámetros se rechaza. Establezca un período de retención para que los resultados antiguos no superen la ventana de reintento del negocio. El commit de base de datos y los efectos secundarios externos aún requieren un outbox, sondeo de estado o un diseño de compensación.
5. Restringir los reintentos y el comportamiento del proxy
Los clientes reintentan solo cuando la respuesta es reintentable y la operación cumple con la regla de idempotencia, utilizando backoff exponencial truncado, jitter y un límite de intentos totales. Los gateways, SDKs y consumidores de colas no deben apilar reintentos ilimitados; distinga entre 425, fallo de conexión, rate limiting y rechazo de negocio. Para escrituras de alto valor, permita que el cliente consulte el estado de la clave de idempotencia en lugar de reenviar el efecto secundario original.
6. Monitorear, desplegar y ejecutar fallback
Comience con rutas de lectura y un conjunto reducido de tenants, conservando selectores de activación por ruta, cliente y región. Rastree el volumen de early data, la tasa de 425, conflictos de claves duplicadas, cobros duplicados o anomalías de inventario, amplificación de reintentos, latencia de handshake completo y errores en el almacén de desduplicación. Si se cruzan los umbrales, detenga el despliegue, deshabilite early data o fuerce un handshake completo, y conserve muestras de auditoría para determinar si una solicitud realmente se ejecutó.
Modelo de respuesta de alta calidad
Trataría early data como una entrada potencialmente repetible, no como una solicitud HTTPS ordinaria. El edge detecta y protege la señal; las lecturas continúan solo cuando su riesgo es aceptable, mientras que las órdenes, cobros, inventario, permisos y notificaciones externas devuelven 425 y requieren un handshake completo. Para las escrituras que necesitan baja latencia, el cliente debe enviar una clave de idempotencia vinculada al tenant, la operación y el digest de parámetros. El servidor persiste los estados de procesamiento, éxito y fallo detrás de una restricción única y rechaza los conflictos de parámetros. Defina las condiciones de reintento por separado para 425, fallo de conexión y rate limiting; los clientes utilizan backoff exponencial acotado y jitter, mientras que el gateway evita los reintentos automáticos infinitos. Despliegue gradualmente y monitoree 425, claves duplicadas, ejecución duplicada de negocio, amplificación de reintentos, latencia de fallback y fallos de desduplicación. Deshabilite early data o fuerce un handshake completo ante anomalías, y luego concilie los registros de auditoría.
Errores comunes
- Asumir que el cifrado TLS implica que early data no puede repetirse.
- Clasificar únicamente por el nombre del método en lugar de los efectos secundarios reales de negocio.
- Permitir que tanto el gateway como el cliente reintenten 425 sin un límite.
- Omitir la vinculación del tenant y de los parámetros en la clave de idempotencia.
- Cachear únicamente el éxito e ignorar el estado de procesamiento o la semántica de fallos reintentables.
- Medir las mejoras de latencia sin considerar cobros duplicados, anomalías de inventario o amplificación de reintentos.
- Omitir la deshabilitación a nivel de ruta, el fallback a handshake completo y la conciliación de auditoría.
Preguntas de seguimiento y respuestas
¿Cuál es la diferencia entre 425 y 429?
425 significa que la solicitud llegó demasiado pronto bajo la condición actual de early data y debe enviarse nuevamente tras un handshake completo. 429 significa que la solicitud alcanzó un límite de tasa (rate) o cuota. Sus condiciones de reintento, sugerencias de espera y significados en el monitoreo difieren, por lo que no deben compartir la misma rama de reintento automático.
¿Qué pasa si el cliente no soporta 425?
Para rutas de escritura críticas, rechace early data en el gateway o fuerce un handshake completo en lugar de depender de la interpretación del cliente. Distribuya el comportamiento de compatibilidad en un SDK actualizado. Las rutas de solo lectura pueden continuar, pero registre la capacidad del cliente y el límite de riesgo.
¿Debe continuar un cobro si el almacén de idempotencia está caído?
No realice un efecto secundario de alto riesgo cuando no se pueda demostrar la desduplicación. Devuelva un error reintentable, recurra a un handshake completo y vuelva a verificar, o convierta la solicitud a un estado pendiente consultable. Elija según el límite de pérdidas y la vía de recuperación.
¿Podría ejecutarse una solicitud de early data después de que el servicio devuelva 425?
Existe una condición de carrera en la que la solicitud ya ha llegado a la aplicación, por lo que la aplicación debe volver a verificar la señal de early data y el estado de idempotencia antes de ejecutar el efecto secundario. Un 425 no revoca una operación ya iniciada. Confirme los efectos secundarios mediante la máquina de estados y la restricción única, y luego utilice registros de auditoría para confirmar la ejecución.