Planteamiento y contexto
La plataforma cuenta con cientos de instancias de gateway distribuidas en múltiples regiones. Los equipos de producto necesitan cuotas de solicitudes por segundo, concurrencia y cuotas diarias por inquilino, aplicación, endpoint y plan, con cambios que surtan efecto en cuestión de minutos. Ningún inquilino debe consumir la capacidad compartida; sin embargo, las API principales deben seguir disponibles durante una interrupción breve del servicio de cuotas.
La entrevista evalúa la separación entre el plano de control y el plano de datos, los modelos de conteo, la consistencia en la distribución, las compensaciones entre regiones y el comportamiento ante fallas. Envoy distingue entre rate limiting local y global, mientras que la RFC 9331 define los campos de RateLimit en HTTP; conecta el protocolo, la política del producto y la decisión en tiempo de ejecución.
Qué evalúa el entrevistador
Cubre la estructura de las políticas, versiones y aprobación, claves descriptoras, token bucket o ventanas deslizantes, inquilinos de alto tráfico (hot tenants), conteo interregional, distribución de configuración, almacenamiento en caché, fail-open frente a fail-closed, encabezados de cuotas, auditoría y costos.
Preguntas de clarificación para hacer
- ¿Las cuotas son límites estrictos (hard limits), alertas suaves (soft alerts) o ambos, y se permite que el tráfico tenga ráfagas o tome prestada capacidad futura?
- ¿Qué dimensiones requieren precisión global y cuáles admiten una aproximación regional acotada?
- ¿Cuáles son los objetivos de propagación y reversión (rollback), y cuánto tiempo puede estar desconectado un gateway antes de considerar una política como obsoleta (stale)?
- ¿Debe una respuesta que excede el límite exponer los tiempos de reintento, la cuota restante y eventos de facturación?
- ¿Qué endpoints críticos deben continuar operando durante una caída del limitador?
Una respuesta de 30 segundos
“El plano de control almacena políticas aprobadas y versionadas, las compila en descriptores de gateway y distribuye los deltas. El plano de datos toma decisiones rápidas locales; solo las dimensiones que requieren precisión global consultan a un limitador compartido. Los token buckets absorben las ráfagas y los contadores se aíslan por inquilino y endpoint. Las políticas llevan TTL, checksum y versión de reversión. Se elige fail-open o fail-closed según el riesgo del endpoint, se devuelve información estándar de RateLimit y se audita el motivo de la decisión.”
Análisis detallado paso a paso
Paso 1: Definir la política y el flujo de trabajo de publicación
Una política contiene inquilino, aplicación, endpoint, ventana, tasa, capacidad, concurrencia, cuota diaria, alcance regional y prioridad. Los gateways no deben interpretar campos arbitrarios de producto; el plano de control los compila en descriptores estables.
policy v42:
subject: tenant:acme / app:billing
route: POST /invoices
rate: 200 requests/second
burst: 400
scope: globalLa publicación requiere aprobación, verificaciones estáticas de conflictos, simulación de tráfico y una versión firmada. Conserva el autor, el motivo, el impacto esperado y el puntero de reversión; nunca sobrescribas una versión auditada.
Paso 2: Elegir el conteo y el particionamiento (sharding)
Usa un token bucket local en el gateway para ráfagas cortas. Un limitador compartido puede contar dimensiones globales por descriptor. Para cuotas diarias, usa contadores de ventana atómicos o cuotas particionadas, con límites de ventana explícitos y una fuente de reloj.
Particiona por inquilino, aplicación y endpoint para que una clave caliente (hot key) no se convierta en el cuello de botella. Un inquilino de alto tráfico puede recibir tokens jerárquicos, capacidad preasignada o un shard dedicado, con un tratamiento explícito de los excesos breves y la facturación final.
Paso 3: Distribuir la política con consistencia
Transmite mediante streaming las políticas compiladas con versión y checksum a los gateways. Acepta solo versiones válidamente firmadas y que aumenten de forma monótona; carga la última instantánea válida al iniciar. Las actualizaciones faltantes marcan el gateway como obsoleto tras su TTL y emiten una alerta.
Prioriza la distribución local dentro de una región. La política interregional utiliza una versión global y un tiempo de vigencia explícito. Una reversión es otra versión más, nunca una reescritura del historial; los gateways reportan la cobertura de versiones tras la confirmación.
Paso 4: Manejar la consistencia, las ráfagas y la equidad
El conteo global exacto añade latencia de red y costos de estado compartido. Reserva la coordinación estricta para dimensiones contractuales o de alto riesgo y permite un error acotado en el resto. Alinea la capacidad de ráfaga con la concurrencia del backend; aumentar únicamente el bucket del gateway aún puede sobrecargar el servicio.
La equidad entre inquilinos debe proteger los pools de conexiones compartidos. Vincula las decisiones de cuota con mamparas de concurrencia (bulkheads), longitud de cola y prioridad. Registra si el tráfico fue rechazado o puesto en cola y por qué, para que los clientes puedan diagnosticar más que un simple número.
Paso 5: Definir fallas y degradación
Si el limitador no está disponible, los endpoints de solo lectura de bajo riesgo pueden usar la instantánea local más reciente con fail-open acotado; las escrituras, la facturación y los endpoints costosos usan fail-closed o un límite local más estricto. Asigna a cada decisión degradada una expiración y concilia o marca los conteos aproximados tras la recuperación.
Pon a prueba reinicios de gateways, desviaciones de reloj (clock drift), mensajes duplicados e interrupciones en la distribución. Rechaza una instantánea corrupta y conserva la última versión válida; una configuración vacía nunca debe significar cuota ilimitada.
Paso 6: Protocolo, auditoría y observabilidad
Devuelve una semántica 429 estable en respuestas que superen el límite y expón información interpretable de límite, restante y restablecimiento conforme a la RFC 9331. Para los inquilinos que no deben ver números exactos, utiliza un mensaje por niveles. Registra internamente la versión de la política, descriptor, región, fuente del contador, estado degradado y traza de la solicitud.
Monitorea la cobertura de versiones, la latencia de decisión, la tasa de rechazo, las claves calientes, el error de conteo, la duración de la degradación y las reversiones. Evalúa nuevas políticas en modo shadow y compara los cambios en los rechazos antes de la publicación.
Una respuesta de ejemplo sólida
Compilaría las políticas aprobadas en descriptores versionados y distribuiría deltas desde el plano de control. Los gateways utilizan token buckets locales para una baja latencia, consultando un servicio compartido solo para las dimensiones que necesitan precisión global. Las políticas llevan firmas, TTL, checksums y versiones de reversión, aisladas por inquilino, aplicación, endpoint y región. Se degrada según el riesgo del endpoint, se devuelve un 429 estable e información de RateLimit, y se registra la versión, la fuente del contador y el estado de aproximación.
Errores comunes
- Enviar cada solicitud a un contador central → la latencia y el dominio de falla crecen → toma decisiones locales y coordina globalmente según el riesgo.
- Sobrescribir la configuración → sin auditoría ni reversión → utiliza aprobación, firmas y versiones monótonas.
- Establecer la tasa sin ráfaga ni concurrencia → el backend aún puede inundarse → vincula tokens, bulkheads y colas.
- Hacer siempre fail-open → las escrituras y la facturación se vuelven ilimitadas → degrada según el riesgo del endpoint.
- Devolver un error vago → los clientes no pueden ajustar el tráfico → proporciona un estado estable, tiempos de restablecimiento y un motivo auditable.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no exigir consistencia estricta en todas partes?
La consistencia estricta requiere estado compartido y viajes de ida y vuelta por la red (round trips), lo que reduce la disponibilidad e incrementa los costos. Resérvala para dimensiones contractuales o críticas para la seguridad y publica el modelo de error acotado en el resto.
Pregunta de seguimiento 2: ¿Cómo manejas una ráfaga interregional?
Preasigna tokens regionales bajo un tope global. El tráfico de alto valor puede tomar prestado brevemente, pero registra la capacidad prestada y las reglas de reembolso o facturación para que una región no pueda dominar.
Pregunta de seguimiento 3: ¿Quién es responsable del retraso de propagación?
El gateway mantiene su última versión válida y se marca como obsoleto mientras el plano de control monitorea la cobertura. Después del TTL, restringe o pausa según el riesgo del endpoint; nunca pases silenciosamente a cuota ilimitada.
Pregunta de seguimiento 4: ¿Cómo demuestras que una nueva política no perjudica a los clientes?
Ejecuta una evaluación shadow y reproducción histórica, compara las distribuciones de rechazo, latencia e inquilinos, establece puertas de enlace automatizadas y luego despliega en canary de forma acotada con una versión de reversión de un solo clic.