La pregunta y cuándo aplica
Una API de plano de control atiende comprobaciones de estado, escrituras de controladores, consultas de inquilinos y watches de larga duración. Un pico de tráfico o un inquilino ruidoso pueden ralentizar todas las solicitudes. Diseña controles de prioridad y equidad, y explica cómo interactúan la clasificación, los límites de concurrencia, las colas, los tiempos de espera y la degradación.
Qué evalúa el entrevistador
- Transformar el concepto de "importante" en clases de solicitudes auditables en lugar de privilegios de equipo permanentes.
- Proteger el plano de control con cupos, colas y cuotas en lugar de depender únicamente de un limitador de tasa en el ingreso.
- Explicar la granularidad de la equidad, la ocupación por solicitudes largas, el aislamiento de inquilinos y la degradación ante fallos.
- Validar el diseño mediante latencia, tasa de rechazo, antigüedad en cola y tiempo de recuperación del controlador.
Preguntas de clarificación antes de responder
- ¿Cuáles solicitudes son escrituras críticas para la seguridad y qué lecturas o watches pueden retrasarse?
- ¿La equidad se calcula por inquilino, identidad, carga de trabajo o tipo de recurso? ¿Se permite una ruta de administración para emergencias?
- ¿Se está protegiendo el servidor de la API, el almacenamiento downstream o ambos?
- ¿Las solicitudes largas consumen múltiples cupos y cómo se liberan los cupos ante una desconexión?
- ¿La sobrecarga puede devolver un error 429 o el sistema debe preservar una tasa mínima de éxito y una señal de reintento?
Estructura de respuesta en 30 segundos
Mapearía las solicitudes por identidad, método y recurso en flujos de prioridad delimitados, y luego asignaría a cada flujo cupos de concurrencia y una cola equitativa. La alta prioridad obtiene una capacidad base acotada; la baja prioridad se encola o se rechaza bajo presión. Las solicitudes largas se clasifican por separado y se les cobra su ocupación continua. Cada rechazo lleva una señal de reintento procesable. Condicionaría el despliegue a la latencia p99, la antigüedad en cola, la tasa de 429, la saturación downstream y el tiempo de recuperación de los controladores críticos.
Análisis detallado paso a paso
Paso 1: Construir clases de solicitudes explicables
Clasifica a partir de una identidad verificable, método HTTP, recurso de destino y estado de larga duración. No permitas que los clientes envíen un campo arbitrario de "alta prioridad". Divide las escrituras de controladores, latidos de nodos, consultas de administración y listados masivos en flujos distintos, y registra la regla coincidente.
Paso 2: Modelar la capacidad como cupos
Los cupos representan capacidad de servicio simultánea en lugar de solo recuento de solicitudes. Una lectura rápida puede consumir un cupo; una consulta lenta o un watch pueden requerir más. Libera cupos al completarse o cancelarse la solicitud. Asigna a cada prioridad un límite nominal mientras mantienes un tope global de cupos para que las capacidades base no excedan la capacidad segura.
Paso 3: Aplicar colas equitativas dentro de cada prioridad
Dentro de una prioridad, utiliza una cola equitativa ponderada indexada por inquilino o identidad de flujo para que un solo inquilino no sature la clase. Despacha un flujo no vacío que esté por debajo de su límite actual. El envejecimiento (aging) puede aumentar el peso de una solicitud retrasada repetidamente, pero no debe eludir el tope global de cupos.
Paso 4: Manejar solicitudes largas y dependencias
Asigna a los watches y al seguimiento de registros (log tails) presupuestos separados, duraciones máximas y cancelación por latidos. Coloca mamparas (bulkheads) de concurrencia independientes alrededor del almacenamiento, cachés y servicios externos; una cola de ingreso no debe transferir presión ilimitada hacia downstream. Reintenta solo fallos reintentables, con retroceso exponencial (exponential backoff) y jitter.
Paso 5: Definir acciones de sobrecarga
A medida que aumenta la presión, pausa el nuevo trabajo de baja prioridad, luego restringe los listados masivos y los filtros costosos, y finalmente devuelve 429 cuando una solicitud no pueda encolarse. Incluye una indicación clara de tiempo de espera en la respuesta; los clientes aún necesitan topes de reintento, jitter y límites de tiempo (deadlines). Si una escritura crítica no puede descartarse, colócala en una cola duradera y devuelve un ID de operación consultable.
Paso 6: Observar la equidad, no solo la latencia promedio
Monitorea p50, p99, antigüedad en cola, ocupación de cupos, 429s, cancelaciones y errores downstream por prioridad, inquilino y tipo de solicitud. Genera alertas por espera máxima, éxito de escrituras críticas, tiempo de recuperación y disparidad de servicio entre inquilinos. Las pruebas de carga deben incluir ráfagas de un solo inquilino, agotamiento de cupos por solicitudes largas, clasificación errónea y recuperación del controlador.
Paso 7: Evolucionar y revertir de forma segura
Registra nuevas coincidencias de clasificación en modo solo observación antes de aplicar límites. Versiona y audita la configuración, y mantén una ruta operativa restringida. Cuando cambien los cupos o las prioridades, compara la capacidad downstream y las distribuciones históricas de colas; no confíes únicamente en las métricas de la capa de API.
Ejemplo de respuesta de alta calidad
Modelaría la capacidad del plano de control como un fondo global de cupos. Las solicitudes se asignan a flujos de prioridad utilizando identidad, método, recurso y atributos de larga duración. Las escrituras de controladores y los latidos de nodos obtienen cupos base, pero la suma de las bases se mantiene por debajo de la capacidad segura. Las lecturas ordinarias de inquilinos comparten una cola equitativa ponderada. Los watches se tarifican por separado y tienen duraciones máximas; la cancelación libera cupos de inmediato. Durante una sobrecarga, se pausan las lecturas masivas, se restringen los filtros costosos y se devuelve 429 con una sugerencia de espera cuando el trabajo no pueda encolarse. Las escrituras que deban completarse van a una cola duradera. Antes de la aplicación de límites, mediría las coincidencias de clasificación y la antigüedad en cola por inquilino; tras el despliegue, el éxito de escrituras críticas, p99, 429s, la saturación downstream y el tiempo de recuperación se convierten en compuertas de reversión.
Errores comunes
- Configurar únicamente un límite global de QPS, permitiendo que las solicitudes largas agoten la concurrencia.
- Otorgar a un administrador o inquilino prioridad ilimitada, creando una inanición inauditable.
- Cobrar solo por recuento de solicitudes sin modelar de forma distinta lecturas, listados y watches.
- Hacer que cada cliente reintente el 429 de inmediato, creando una tormenta de reintentos sincronizada.
- Mirar únicamente la latencia promedio e ignorar la espera máxima en las colas de baja prioridad.
- Cambiar límites sin una prueba canario, versionado o ruta de reversión.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no usar únicamente un token bucket?
Un token bucket limita la tasa de llegada, pero no expresa diferentes costos de concurrencia, la ocupación de solicitudes largas ni la equidad entre inquilinos. Puede ser una capa de ingreso, pero aún se requieren cupos y colas.
Pregunta de seguimiento 2: ¿Puede la alta prioridad provocar inanición en la baja prioridad?
Sí, a menos que la alta prioridad también tenga límites y el sistema imponga cuotas reservadas, un máximo de servicio consecutivo o envejecimiento (aging). Una ruta de emergencia debe permanecer auditada y con capacidad acotada.
Pregunta de seguimiento 3: ¿Cuántos cupos debería consumir un watch?
No existe una constante universal. Mide las conexiones, la tasa de eventos, el costo de serialización y la presión de consultas downstream, elige una base conservadora y calibra con pruebas de carga. Los tiempos de espera y las desconexiones deben liberar cupos.
Pregunta de seguimiento 4: ¿Quién decide el tiempo de reintento para el 429?
El servidor proporciona una sugerencia de espera mínima basada en la recuperación esperada; el cliente añade retroceso exponencial, jitter y un límite de tiempo. La sugerencia no es una garantía de capacidad, por lo que los clientes deben seguir limitando los intentos.
Pregunta de seguimiento 5: ¿Cómo se demuestra la equidad?
Define objetivos a nivel de inquilino, tales como cuota de cupos, antigüedad máxima en cola y tasa de finalización dentro de una prioridad. Compara las distribuciones durante una ráfaga de un solo inquilino y bajo carga mixta en lugar de reportar solo una media global.
Pregunta de seguimiento 6: ¿Qué sucede si una regla clasifica erróneamente una escritura crítica como de baja prioridad?
Mantén registros de coincidencia de reglas y revisión humana, y publica la configuración como un artefacto versionado. Si la tasa de éxito de escrituras críticas cae, revierte la versión de clasificación de inmediato y utiliza una ruta de seguridad restringida para el trabajo encolado.