Planteamiento y contexto
Esta pregunta de diseño de sistemas evalúa si puedes transformar parámetros de bajo nivel de TCP keep-alive en una funcionalidad de plataforma gobernada. El desafío no radica simplemente en enviar sondeos con mayor frecuencia. Separa la vivacidad del transporte de la salud de la aplicación y, a continuación, diseña el aislamiento de inquilinos, las versiones de políticas, el ciclo de vida de las conexiones, el costo de red y la recuperación.
Qué evalúa el entrevistador
- Explicar la relación entre el tiempo de inactividad, el intervalo de sondeo, los fallos máximos y los falsos positivos.
- Diseñar valores predeterminados seguros, cuotas por inquilino, permisos y validación de configuraciones.
- Aplicar una política en un punto apropiado del ciclo de vida de la conexión sin causar churn durante actualizaciones en caliente.
- Proporcionar auditabilidad, métricas, despliegue escalonado, reversión y protección contra sobrecargas.
Preguntas para clarificar
Confirma los tipos de conexión, el control del cliente y del servidor, los nodos compartidos, NAT, redes móviles, proxies y el objetivo de negocio para detectar una conexión muerta. Comprueba el soporte del kernel, si keep-alive está deshabilitado por defecto, los heartbeats existentes a nivel de aplicación, la cantidad de conexiones y los presupuestos por inquilino, y si los cambios deben ser inmediatos. Un sondeo TCP solo establece la respuesta del transporte; no reemplaza una verificación de salud a nivel de aplicación.
Estructura para una respuesta de 30 segundos
Construiría un servicio versionado de políticas para inquilinos con valores predeterminados globales conservadores y límites por inquilino, validando la combinación de tiempo de inactividad, intervalo de sondeo y recuento de fallos. Las nuevas conexiones leen y se vinculan a una versión de política; la actualización en tiempo de ejecución se controla para evitar reiniciar una cantidad masiva de sockets. La publicación requiere autorización, auditoría, despliegue escalonado y reversión automática, mientras que el plano de datos registra sondeos, desconexiones y falsos positivos. Limitaría el presupuesto total de sondeos, seguiría utilizando la última versión válida cuando el plano de control no esté disponible y reservaría los heartbeats de la aplicación para la semántica de negocio.
Diseño paso a paso
1. Definir el modelo de políticas y valores predeterminados seguros
Incluye idle-time, probe-interval, max-probes, alcance de la conexión, versión, expiración y origen. RFC 9293 exige que keep-alive sea conmutable por conexión y esté deshabilitado por defecto; RFC 9643 recomienda intervalos conservadores porque los sondeos consumen recursos. Utiliza un tiempo de inactividad e intervalo predeterminados lo suficientemente largos y permite que los inquilinos los acorten únicamente dentro de un presupuesto de recursos.
2. Separar el plano de control y el plano de datos
El plano de control almacena las políticas de inquilinos, versiones y registros de auditoría, y expone la validación, aprobación, publicación, despliegue y reversión. Tras el establecimiento de la conexión o el handshake, el plano de datos lee una instantánea firmada, la aplica al socket controlable y reporta la versión efectiva. Una breve interrupción del plano de control no debe fallar todas las conexiones; almacena en caché la última instantánea válida y define el comportamiento ante expiración.
3. Validar combinaciones y cuotas
Rechaza intervalos de sondeo inferiores a un límite mínimo seguro, topa el recuento de conexiones y las tasas de sondeo por inquilino, y verifica que el recuento de fallos coincida con el objetivo de tiempo de detección. Calcula presupuestos por nodo, zona y ruta de egreso para que un inquilino no pueda concentrar sondeos en un solo grupo de instancias. Aplica un segundo límite basado en la carga del nodo en tiempo real, incluso después de la validación de configuración.
4. Distribuir versiones y gestionar actualizaciones
Vincula una versión de política a cada conexión, haciendo que las nuevas conexiones utilicen la última versión publicada. Las conexiones existentes pueden actualizarse por lotes, mediante reconexiones naturales o en el siguiente ciclo de inactividad; no actualices millones de sockets a la vez. Escala cada lanzamiento a un conjunto reducido de inquilinos y nodos, compara el tiempo de detección, falsos positivos, CPU, ancho de banda y churn de conexiones, y luego expándelo.
5. Desarrollar observabilidad y clases de fallo
Registra la versión de la política, los sondeos enviados, la tasa de respuesta, los fallos consecutivos, el motivo final de desconexión, el éxito de la reconexión y el uso de recursos por inquilino. Distingue entre cierre del par, pérdida de paquetes, sobrecarga del nodo, política expirada y fallo del heartbeat de la aplicación. La sola ausencia de respuesta de keep-alive no prueba la muerte de la conexión; las alertas deben combinar sondeos repetidos con resultados de la aplicación.
6. Diseñar la reversión y protección contra sobrecargas
Conserva la versión estable anterior y una política global de emergencia. Si un despliegue incrementa las desconexiones, el tráfico de sondeo o la CPU por encima de los umbrales, detén la publicación y restaura la versión anterior; si las actualizaciones fallan, continúa con una instantánea validada. Agrega límites de tasa, disyuntores por inquilino y contrapresión en colas para que una tormenta de políticas no abrume al gestor de conexiones.
Respuesta de ejemplo de alta calidad
Implementaría las políticas de keep-alive como un servicio versionado del plano de control que contenga tiempo de inactividad, intervalo de sondeo, sondeos máximos, alcance de la conexión y datos de auditoría. La plataforma utilizaría un valor predeterminado global conservador y deshabilitado, y limitaría las configuraciones de los inquilinos mediante presupuestos de conexiones y sondeos. Las nuevas conexiones leerían una instantánea firmada y se vincularían a su versión; las conexiones existentes solo se actualizarían a través de lotes o reconexiones naturales. El despliegue requeriría aprobación, métricas escalonadas y reversión automática, rastreando la tasa de sondeos, respuestas, causas de desconexión, falsos positivos, reconexiones y carga del nodo. Keep-alive cubriría la vivacidad del transporte mientras que los heartbeats de la aplicación confirmarían la salud del negocio. Si el tráfico de sondeos o las desconexiones aumentaran de forma inesperada, detendría la propagación y restauraría la versión estable.
Errores comunes
- Tratar keep-alive como una verificación de salud de la aplicación solo porque llegó un ACK.
- Permitir que los inquilinos reduzcan los intervalos sin presupuestos de sondeos por nodo, egreso y globales.
- Recorrer cada conexión inmediatamente después de un cambio de política y provocar un churn sincronizado.
- Omitir versiones, firmas, registros de auditoría y una instantánea del último estado bueno conocido.
- Observar únicamente los recuentos de desconexión sin clasificar pérdidas, cierres del par, sobrecarga y falsos positivos.
- Publicar globalmente sin un despliegue escalonado o una ruta de reversión.
Preguntas de seguimiento y respuestas
¿Por qué no configurar el intervalo de sondeo en unos pocos segundos?
Los sondeos frecuentes consumen recursos de red, CPU y batería, y pueden amplificar la congestión. Calcula los parámetros a partir del objetivo de detección, la cantidad de conexiones y el presupuesto de recursos, y prioriza un heartbeat de aplicación cuando se requiera semántica de negocio.
Un inquilino desea un cambio inmediato. ¿Qué haces?
Permite que las nuevas conexiones utilicen la versión aprobada de inmediato y actualiza las conexiones existentes a través de lotes acotados con límites de tasa por nodo. Los cambios de seguridad de emergencia pueden recibir mayor prioridad, pero aún requieren un aprobador, alcance, churn esperado y una condición de reversión.
¿Qué sucede cuando el plano de control está caído?
El plano de datos continúa utilizando la última instantánea firmada no expirada durante un período acotado. Tras la expiración, recurre a un valor predeterminado global seguro, no a una configuración vacía. Una vez recuperado, concilia las versiones sin refrescar todas las conexiones al mismo tiempo.
¿Cómo detectas un falso positivo de keep-alive?
Compara los fallos de sondeo consecutivos con los heartbeats de la aplicación, los resultados de reconexión y las métricas de ruta. Un solo ACK no recibido es insuficiente; exige el recuento de fallos configurado y señales de negocio o de aplicación que lo corroboren.
¿Cómo evitas que un inquilino grande consuma el presupuesto de sondeos?
Utiliza cuotas jerárquicas por inquilino, nodo, zona y globales basadas en la cantidad de conexiones y la tasa de sondeos. Por encima de la cuota, alarga los intervalos, rechaza configuraciones agresivas o exige una ampliación de cuota mientras preservas un nivel mínimo de servicio para los demás.