Planteamiento y contexto
Un inquilino (tenant) adquiere una asignación global de 30,000 solicitudes por minuto con una capacidad de ráfaga (burst) de 6,000. El tráfico entra a través de tres regiones activas, y tomar una decisión interregional en cada solicitud incumpliría el objetivo de latencia. Diseñe únicamente la capa de coordinación global; asuma que cada región ya cuenta con un token bucket local correcto.
La respuesta debe cuantificar qué sucede cuando la demanda se traslada entre regiones, cuando una región queda particionada o cuando el coordinador falla. HTTP 429 y Retry-After comunican el rechazo a los clientes, pero no determinan el algoritmo interno de limitación.
Qué evalúa el entrevistador
- Si usted señala que la baja latencia, la disponibilidad ante particiones y un límite global exacto no pueden asumirse simultáneamente.
- Si la cuota se conserva a través de los arrendamientos (leases) en lugar de copiarse a cada región.
- Si la capacidad no utilizada puede recuperarse sin incurrir en doble gasto.
- Si la política de fallas y el exceso máximo permitido son medibles.
Preguntas de clarificación para hacer
- ¿La cifra global es un límite estricto de abuso o un objetivo comercial con margen de error tolerado?
- Durante una partición, ¿debe una región detenerse cuando su arrendamiento se agote o continuar dentro de una asignación de emergencia?
- ¿Con qué rapidez puede trasladarse el tráfico y qué tan desigual puede llegar a ser la demanda regional?
- ¿Cada solicitud tiene un costo unitario o los endpoints consumen un costo ponderado?
- ¿Es preferible una subutilización temporal antes que un exceso de consumo?
Para un límite estricto, una región particionada solo puede usar su arrendamiento no vencido. Un límite comercial de mejor esfuerzo (best-effort) puede permitir una asignación de emergencia explícitamente delimitada.
Una respuesta de 30 segundos
“Utilizaría un coordinador con ordenamiento estricto para gestionar dos recursos arrendables: una tasa de recarga global de 500 solicitudes por segundo y una capacidad de ráfaga global de 6,000. Este arrienda fracciones de corta duración de tasa de recarga y de ráfaga a las regiones, las cuales consumen mediante sus token buckets atómicos locales existentes. En todo momento, la suma de los arrendamientos activos superpuestos es como máximo de 500 solicitudes por segundo y 6,000 tokens de ráfaga; la renovación actualiza los parámetros sin rellenar el saldo local. Durante un cambio de tráfico, una cuota anterior debe devolverse o expirar antes de reasignarse. Una región con límite estricto se detiene tras la expiración del arrendamiento durante una partición; una región con mejor esfuerzo puede usar una asignación de emergencia independiente cuya suma constituye el límite de exceso documentado.”
Análisis detallado paso a paso
1. Preservar la cuota como un invariante de conservación
Convierta 30,000 solicitudes por minuto a una tasa de recarga continua de R = 500 req/s, con una capacidad de ráfaga de B = 6000. En todo momento, sum(active_lease.refill_rate) <= R y sum(active_lease.burst_capacity) <= B. Un arrendamiento contiene tenant, región, época (epoch), fracción de tasa, fracción de ráfaga, hora de activación, expiración y un ID único. Los saldos regionales iniciales suman como máximo B, y una renovación, ampliación o reconfiguración no puede crear saldo de la nada; por lo tanto, el total de admisiones en cualquier intervalo es como máximo de R × duration + B. La conmutación por error (failover) utiliza un registro de arrendamientos duradero y una época superior; los arrendamientos existentes cuentan para ambos límites hasta su devolución confirmada o expiración.
2. Consumir localmente y renovar antes del agotamiento
El bucket regional se recarga a su tasa arrendada y limita su saldo a la fracción de ráfaga arrendada; cada solicitud se decrementa de forma atómica. Una renovación ininterrumpida extiende o modifica la tasa y la capacidad mientras preserva el saldo existente, truncándolo cuando la capacidad disminuye en lugar de volver a llenar el bucket. Tras una interrupción en el arrendamiento, el siguiente comienza con saldo cero a menos que el coordinador transfiera tokens recuperados confirmados. Los arrendamientos más cortos facilitan el reequilibrio y reducen los límites de falla, pero aumentan la carga de renovación. Elija la duración a partir de los picos medidos, la capacidad del coordinador y el tiempo de desconexión tolerado.
3. Reequilibrar sin doble gasto
Las regiones en buen estado informan su saldo y demanda. El coordinador reduce la tasa y la fracción de ráfaga de la región fría en su próximo arrendamiento, y luego asigna las fracciones liberadas a la región caliente. Hasta que el arrendamiento anterior se confirme como devuelto o expire, los arrendamientos antiguos y nuevos superpuestos se contabilizan en ambos límites. La confirmación de devolución invalida primero el bucket antiguo; aumentar la capacidad en la región caliente no crea saldo, el cual comienza en cero o recibe únicamente tokens transferidos confirmados. Las devoluciones son idempotentes; ante un estado incierto, es preferible subutilizar temporalmente antes que asignar la misma fracción dos veces.
4. Definir explícitamente la semántica de fallas
Con un límite estricto, una región solo se recarga mientras su arrendamiento sea válido. Si no puede renovar, la expiración invalida el bucket local y descarta cualquier saldo que no haya sido transferido mediante una devolución confirmada; el costo es una subutilización temporal. Si cada región tiene una asignación de emergencia E fuera del límite de ráfaga normal, la asignación adicional máxima es la suma de los presupuestos que pueden activarse mientras se está desconectado, y ese modo no puede garantizar un exceso estrictamente nulo. La falla del coordinador no invalida los arrendamientos emitidos. Un reemplazo restaura el registro duradero, cerca (fence) al emisor anterior con una época superior y continúa contabilizando los arrendamientos antiguos no vencidos.
Un ejemplo de respuesta sólida
“Los token buckets regionales existentes permanecen en la ruta síncrona. Añado un coordinador global que representa 30,000 solicitudes por minuto como una tasa de recarga de 500 solicitudes por segundo y gestiona por separado 6,000 solicitudes de capacidad de ráfaga. Este emite cuotas de tasa y ráfaga delimitadas por época y con expiración, garantizando que los arrendamientos activos sumen como máximo 500 solicitudes por segundo y 6,000 tokens de ráfaga.
Cada región recarga su bucket local a la tasa arrendada y lo limita a la fracción de ráfaga arrendada. Las renovaciones ininterrumpidas preservan el saldo, y la capacidad adicional no genera saldo nuevo. Una región caliente recibe solo tokens devueltos confirmados, o comienza a recargarse desde cero después de que expire el arrendamiento frío. Bajo un límite estricto, una región particionada invalida su bucket tras la expiración del arrendamiento. Si el negocio autoriza 100 tokens de emergencia adicionales por región, el exceso documentado por partición es como máximo la suma de los presupuestos de emergencia cuyas reglas de activación puedan superponerse. El failover restaura el registro de arrendamientos y utiliza una nueva época. Probaría cambios de tráfico, devoluciones duplicadas, renovaciones superpuestas, desfase de reloj (clock skew) y particiones de red con respecto a ambos invariantes.”
Errores comunes
- Asignar a cada región la tasa completa y la capacidad de ráfaga total → el límite global se multiplica por el número de regiones → arriende las fracciones de tasa y ráfaga por separado.
- Reutilizar un arrendamiento devuelto antes de confirmar la devolución → los mismos tokens pueden gastarse dos veces → haga que las devoluciones sean idempotentes o espere a la expiración.
- Mencionar “consistencia eventual” sin un margen de error → nadie conoce el posible exceso → especifique los límites de arrendamiento y de presupuesto de emergencia.
- Rellenar el bucket local en cada renovación → cada renovación genera otra ráfaga → preserve el saldo y actualice solo la tasa, la capacidad y la vigencia.
- Hacer failover sin fencing → dos coordinadores podrían emitir cuota válida → asocie una época monotónica a cada arrendamiento.
Preguntas de seguimiento y respuestas
¿Cómo se elige el tamaño del arrendamiento?
Elija la duración, la fracción de tasa de recarga y la fracción de ráfaga por separado. Establezca la duración a partir del tiempo de desconexión tolerado, asigne la tasa según la demanda reciente y asigne la ráfaga a partir de los picos dentro de la capacidad global de 6,000. Una duración más corta agiliza el reequilibrio y reduce el margen de error ante fallas, pero incrementa la carga de renovación.
¿Qué sucede cuando el tráfico cambia repentinamente de región?
El coordinador reduce la tasa y la fracción de ráfaga de la región fría en su próximo arrendamiento, y luego transfiere las fracciones liberadas tras la confirmación de devolución o la expiración del arrendamiento anterior. El sistema puede rechazar solicitudes temporalmente a pesar de tener capacidad no utilizada mientras espera; ese es el costo de evitar una sobreasignación superpuesta.
¿Cómo se devuelve Retry-After?
Utilice el momento más temprano entre la próxima recarga local bajo el arrendamiento actual, una activación confirmada de nuevo arrendamiento o la recuperación esperada del coordinador, redondeado a la precisión admitida por la respuesta. No prometa un tiempo si la recuperación es incierta; devuelva en su lugar una política de reintentos acotada.
¿Puede el diseño garantizar cero exceso y disponibilidad total ante particiones?
Solo si cada partición ya cuenta con suficiente cuota preasignada, lo que puede dejar capacidad ociosa, o si las solicitudes se coordinan sincrónicamente entre regiones, lo que sacrifica la latencia y la disponibilidad ante particiones. La respuesta debe definir explícitamente el límite del producto.