Planteamiento y alcance
Esto evalúa el diseño de protocolos en el límite de la API. El documento de referencia es un Internet-Draft activo publicado el 23 de mayo de 2026, no un RFC; mencione ese estado antes de utilizarlo. El diseño debe seguir siendo seguro si una implementación adopta solo una parte de la propuesta.
Qué evalúa el entrevistador
- Una distinción precisa entre los metadatos de la política y la cuota disponible actual.
- Análisis sintáctico de campos estructurados (structured fields), ventanas múltiples, unidades de cuota y claves de partición.
- Interacción con 429, Retry-After, gateways, CDNs y respuestas en caché obsoletas.
- Riesgos de privacidad y denegación de servicio derivados de exponer los límites.
- Retroceso del cliente que trata las sugerencias como no vinculantes y tolera campos faltantes o con formato incorrecto.
Estructura de respuesta recomendada
Defina primero las dimensiones de la cuota y la propiedad de la misma. Muestre una respuesta que contenga una política y un límite actual, y luego explique cómo un cliente programa el trabajo. Añada reglas de caché e intermediarios, restricciones de seguridad, observabilidad y un plan de despliegue con un feature flag para que el borrador pueda cambiar sin romper a los clientes.
Análisis detallado: hacer útiles los encabezados sin prometer capacidad
Separar la política del estado actual
RateLimit-Policy describe una cuota con nombre, como "tenant";q=1000;w=60. RateLimit informa la cuota disponible y la ventana efectiva, por ejemplo "tenant";r=420;t=23. Una política puede contener múltiples elementos y ventanas variables. El servidor sigue siendo la autoridad: estos valores son sugerencias (hints), no un arrendamiento ni una garantía de nivel de servicio.
Definir la semántica de partición y de unidades
Documente si una unidad de cuota significa una solicitud, un byte, un token o una operación ponderada. Una clave de partición puede distinguir inquilinos o recursos, pero nunca coloque un correo electrónico, un ID de usuario sin procesar o un secreto en un encabezado. Mantenga los nombres de políticas estables y versionados; cambiar las unidades sin cambiar el identificador de la política hace que el ritmo del cliente (pacing) sea inseguro.
Coordinar 429 y Retry-After
Devuelva Retry-After cuando el servidor sepa cuándo se puede volver a intentar una solicitud rechazada. Si ambos campos están presentes, los clientes dan prioridad a Retry-After; RateLimit ayuda a marcar el ritmo del trabajo futuro. El borrador no exige un algoritmo de limitación de tasa (throttling) en particular, por lo que los clientes aún necesitan retroceso exponencial con límite superior, fluctuación (jitter), plazos límite (deadlines) y una regla de idempotencia para escrituras.
Tratar las cachés y los intermediarios como participantes
Los valores de RateLimit en una respuesta en caché pueden ser obsoletos y deben ignorarse cuando la respuesta tiene una antigüedad actual positiva. Un intermediario que desconozca la semántica de cuotas no debe hacer que la respuesta parezca más permisiva. Un gateway que aplica un límite más estricto puede comunicar esa política más estricta, mientras que la telemetría registra las decisiones del origen y del gateway por separado.
Proteger la disponibilidad y la privacidad
No exponga una ventana de cuota amplia que revele el volumen de tráfico o permita a un atacante amplificar solicitudes. Limite la relación entre la cuota disponible y la ventana efectiva, valide los campos estructurados entrantes e ignore los valores mal formados. Se permite reducir los valores anunciados durante la saturación, pero los clientes deben seguir manejando un rechazo incluso cuando la última sugerencia parecía saludable.
Respuesta de ejemplo
“Versionaría una política con nombre por inquilino y operación, definiría la unidad y emitiría los metadatos de la política por separado de la cuota restante actual. El borrador es un Internet-Draft, por lo que los clientes tratan ambos campos como sugerencias opcionales. Retry-After controla una solicitud rechazada; RateLimit marca el ritmo del trabajo futuro. Las CDNs marcan los valores en caché como obsoletos, los gateways nunca hacen que los límites de origen parezcan más flexibles y las claves de partición no contienen identificadores. Los SDK analizan los campos estructurados a la defensiva, utilizan jitter y una cola compartida, y exponen métricas de límites anunciados versus aplicados antes de que habilitemos el contrato gradualmente.”
Modos de falla comunes y soluciones
- Llamar al borrador un RFC → Registre su estado de Internet-Draft y aíslelo detrás de un contrato versionado.
- Usar la cuota restante como permiso → Trátela como una sugerencia; el servidor aún puede rechazar bajo saturación.
- Devolver identificadores de usuario en claves de partición → Utilice nombres opacos de baja cardinalidad y revise la exposición de la privacidad.
- Confiar en encabezados en caché → Ignore los valores obsoletos y deje que el origen aplique el límite.
- Reintentar cada 429 inmediatamente → Respete
Retry-After, agregue jitter y aplique idempotencia específica para el método.
Rúbrica de evaluación y autoevaluación
Califique la separación entre política y estado, las unidades y particiones, la interacción con 429, el comportamiento de la caché, la privacidad, el ritmo del cliente, la seguridad del despliegue y las métricas. Una respuesta sólida explica qué significa cada encabezado, qué no puede garantizar y cómo se comporta un cliente cuando los campos están ausentes, obsoletos o mal formados.
Preguntas de seguimiento y extensiones
¿Qué ocurre si una respuesta tiene dos ventanas?
Seleccione la restricción que se agotará primero para marcar el ritmo, conservando todos los elementos para observabilidad. El SDK no debe colapsar silenciosamente ventanas con diferentes unidades o claves de partición.
¿Debería una respuesta exitosa incluir RateLimit?
Puede hacerlo, pero el cliente no debe asumir que cada respuesta lo contiene. Emítalo solo cuando sea útil para el producto y asegúrese de que las cachés no conviertan valores antiguos en promesas actuales.
¿Cómo se implementa un borrador en evolución?
Negocie un perfil de encabezado o una versión de política, registre las alternativas (fallbacks) del analizador, haga un despliegue tipo canary por versión de SDK y mantenga estable el comportamiento de 429 más Retry-After mientras los nuevos campos sean opcionales.
¿Qué métricas demuestran que el contrato funciona?
Haga seguimiento de límites anunciados y aplicados, decisiones sobre encabezados obsoletos, tasa de 429, amplificación de reintentos, retraso en cola, éxito eventual y cardinalidad de particiones segura para la privacidad por gateway y versión de SDK.