Consigna y contexto
Esta es una pregunta de criterio de producto. Una API para desarrolladores debe proteger los recursos compartidos sin hacer que las integraciones válidas fallen debido a respuestas 429 opacas. Decida qué limitar, qué identidad es dueña del límite, en qué se diferencian los niveles (tiers), cómo los clientes descubren los límites de forma anticipada y cómo demostrar que la política mejora la confiabilidad sin bloquear el trabajo valioso.
Asuma niveles free, professional y enterprise; el costo de las solicitudes varía según el recuento de requests, la concurrencia, el tamaño de entrada y el cómputo downstream; una ráfaga no debe agotar una dependencia compartida; y la política se puede desplegar y revertir. Los valores de ejemplo como 60 RPM, 10,000 llamadas por mes o una advertencia al 80% son marcadores de posición para reemplazar con datos reales, no estándares de la industria.
Qué está evaluando el entrevistador
El entrevistador busca una estrategia de producto vinculada a restricciones técnicas:
- Definir la tasa (rate), la cuota de uso, la concurrencia y el presupuesto de costos como promesas diferentes;
- Partir del "trabajo por hacer" (job to be done) del desarrollador en lugar de basarse únicamente en el precio del plan;
- Explicar las compensaciones de equidad y abuso al limitar por organización, proyecto, API key, usuario o IP;
- Proporcionar errores predecibles, encabezados, paneles, alertas y una vía para solicitar más capacidad;
- Medir la tasa de éxito, la amplificación de reintentos, el costo de recursos, la retención y la carga de soporte como límites de seguridad (guardrails);
- Planificar un despliegue canary, excepciones, apelaciones, reversión (rollback) y comunicación de cambios de política.
Una respuesta débil se limita a listar "límites bajos para el plan gratuito y límites altos para enterprise". Una respuesta sólida establece qué protege cada límite, qué experimentan los desarrolladores y cómo se verificarán los efectos secundarios.
Preguntas de clarificación para hacer
Pregunte por las restricciones que modifican la política:
- ¿Qué recurso se está protegiendo? ¿La CPU del gateway, conexiones a bases de datos, tokens de modelos, una factura de terceros o una participación equitativa para un tenant? Cada uno puede necesitar una dimensión diferente.
- ¿Qué forma tiene la carga de trabajo? Solicitudes constantes, ráfagas cortas, trabajos por lotes (batch) y conexiones de larga duración no pueden compartir un único número por minuto.
- ¿El límite es estricto (hard) o un presupuesto flexible (soft)? Un límite estricto protege la seguridad; un presupuesto flexible puede encolar, degradar o cobrar un extra, pero debe ofrecer una retroalimentación clara.
- ¿La facturación y la limitación (throttling) se miden en la misma unidad? Los tokens, las llamadas y las conexiones concurrentes pueden necesitar contadores separados; una métrica combinada única es difícil de pronosticar.
- ¿Qué define el éxito? ¿Menos sobrecargas en dependencias, más llamadas exitosas al primer intento, mejor margen bruto o mayor retención de desarrolladores de alto valor? El orden de prioridad cambia la política.
Estructura para una respuesta de 30 segundos
Comience con esto:
"Separo cuatro promesas: los rate limits de ventana corta protegen la capacidad instantánea, una cuota por ciclo de facturación controla el presupuesto, un tope de concurrencia protege los slots de ejecución ocupados y un presupuesto de costos previene una factura impredecible. Utilizaría la organización o el proyecto como identidad principal y emparejaría las dimensiones de solicitudes y recursos con el costo del endpoint. Los niveles agregarían presupuesto, capacidad de ráfaga, concurrencia y respuesta de soporte en lugar de simplemente aumentar las RPM. La documentación, los paneles y los encabezados de respuesta mostrarían la capacidad restante, el tiempo de reinicio y Retry-After. Primero evaluaría la política en modo shadow, la lanzaría en modo canary a un pequeño grupo de tenants y monitorearía la tasa de éxito, la amplificación de reintentos, el costo, las actualizaciones de plan y la retención antes de expandirla o revertirla".
Esto establece las unidades, la experiencia del desarrollador y el ciclo de medición antes de entrar en preguntas de seguimiento técnicas o comerciales.
Análisis paso a paso en profundidad
Convierta los límites en un contrato de producto. Un rate limit define cuántas solicitudes caben en una ventana corta. Una cuota de uso define cuánto recurso cabe en un período de facturación. Un tope de concurrencia define cuántos slots de ejecución pueden ocuparse a la vez. Mantenerlos separados permite que el cliente distinga si un 429 significa una ráfaga, un presupuesto periódico agotado o concurrencia máxima alcanzada. Los trabajos largos también pueden requerir un tiempo máximo de ejecución o un presupuesto de cola.
Deduzca las unidades de la carga de trabajo, no de los nombres de los planes. Las lecturas económicas pueden usar recuentos de solicitudes. Las operaciones costosas pueden requerir bytes de entrada, tokens de salida, segundos de cómputo o unidades de escaneo de base de datos. Mapee primero el flujo de trabajo crítico del cliente y luego elija unidades específicas para cada endpoint. No prometa un único valor de RPM que represente el costo de todos los endpoints.
Elija la identidad y la equidad. La organización o el proyecto suele ser una mejor identidad para una API de pago que la IP: NAT combina múltiples clientes, mientras que rotar keys puede eludir un límite basado solo en API keys. Utilice presupuestos a nivel de organización con concurrencia a nivel de proyecto, y use la IP como una barrera contra el abuso. Las excepciones para enterprise deben ser auditables; una promesa comercial no debe eludir la política de la plataforma.
Diseñe las diferencias entre niveles. El nivel free debe permitir completar una pequeña prueba de extremo a extremo. El nivel professional puede añadir presupuesto de período, capacidad de ráfaga y concurrencia. Enterprise puede sumar capacidad reservada, controles de cumplimiento o soporte dedicado. Cada nivel debe especificar el comportamiento al superar el límite: rechazar, encolar, degradar o cobrar por uso. Aumentar un número sin mejorar la previsibilidad generalmente incrementa la carga de soporte.
Haga que el comportamiento del cliente sea predecible. La documentación, los paneles y los encabezados de respuesta deben mostrar la capacidad restante, el tiempo de reinicio y el ID de solicitud. Ante un 429, los clientes pueden respetar Retry-After; un backoff exponencial con un límite máximo de reintentos evita tormentas de reintentos. No incentive reintentos para errores de negocio no reintentables. Devuelva códigos de error estables y una acción siguiente clara en lugar de solo "Too Many Requests".
Defina métricas de lanzamiento y guardrails. Las métricas principales pueden incluir la tasa de éxito en el primer intento, la tasa de errores 429 en solicitudes válidas, la proporción de clientes que alcanzan el 80% de su presupuesto periódico, el margen por solicitud unitaria, los contactos a soporte, la conversión a planes superiores y la retención a 30 días. Los guardrails incluyen amplificación de reintentos, p99 downstream, eventos de abuso y contención entre tenants. Segmente cada métrica por nivel, endpoint y forma de la carga de trabajo para que los promedios no oculten problemas.
Canary, excepciones y rollback. Primero calcule la nueva política en modo shadow para proyectos internos y algunos clientes sin alterar las respuestas. Compárela con la política anterior antes de aplicarla. Ofrezca una ventana de migración, alertas de presupuesto y un proceso para solicitar capacidad temporal. Si el éxito de llamadas válidas o la amplificación de reintentos cruza un umbral crítico, revierta la versión de la política en lugar de editar filas de la base de datos manualmente.
Pruebe con suposiciones explícitas. Supongamos que un proyecto professional envía 40 solicitudes constantes por minuto y tiene ráfagas de 120. Un límite de 60 RPM cubre el flujo constante pero genera 429s repetidos durante la ráfaga. Una política de ejemplo podría permitir 60 RPM con capacidad de ráfaga de 120 y contabilizar el presupuesto mensual por separado; esto es ilustrativo. Las pruebas de carga deben cubrir ráfagas, concurrencia, múltiples proyectos compartiendo un presupuesto de organización, límites de tiempo de reloj, clientes reintentando y propagación de políticas tras un upgrade.
Ejemplo de respuesta de alta calidad
"Separaría el recurso protegido de la promesa al desarrollador. Los rate limits protegen la capacidad en ventanas cortas, una cuota de período controla el presupuesto y un tope de concurrencia protege los slots de ejecución ocupados; los endpoints costosos añaden unidades de cómputo o tamaño de entrada. Mediría principalmente por organización y secundariamente por proyecto, usando la IP solo como barrera contra abusos para que NAT no agrupe clientes válidos. El nivel free debe permitir completar una pequeña prueba de extremo a extremo, el nivel professional agrega presupuesto periódico, ráfagas y concurrencia, y enterprise añade capacidad reservada, controles de cumplimiento y un aumento temporal auditable. Cada nivel define si el exceso de trabajo se rechaza, se encola, se degrada o se factura.
Los clientes ven la capacidad restante, el tiempo de reinicio y el ID de solicitud en la documentación, los paneles y los encabezados. Un 429 sigue Retry-After, y el SDK utiliza un backoff exponencial limitado para evitar la amplificación por solicitudes duplicadas. Evaluará la nueva política en modo shadow y luego la desplegaría como canary a unos pocos proyectos. Las métricas principales son las llamadas exitosas al primer intento, la tasa de 429 en llamadas válidas, el costo por solicitud unitaria y la conversión de upgrades; los guardrails son la amplificación de reintentos, el p99 downstream, los contactos de soporte y la retención a 30 días. Si los fallos en llamadas válidas cruzan el umbral, revierto la versión de la política y extiendo la migración en lugar de abrir una excepción no auditada para un solo cliente".
El punto clave es la conexión entre las unidades del producto, la previsibilidad, el comportamiento técnico y las decisiones basadas en experimentos. Reemplace cada número con una línea base real; las cuotas de ejemplo no son valores predeterminados.
Errores comunes
- Decir únicamente 'nivel free bajo, nivel enterprise alto'. Eso omite el recurso protegido y el comportamiento al superar el límite. Vincule cada límite a un recurso, al trabajo del cliente y a una vía de retroalimentación.
- Tratar las RPM como el costo total. Las solicitudes grandes y los trabajos largos consumen más capacidad downstream. Añada dimensiones de recursos o concurrencia.
- Usar la IP como la única identidad del cliente. NAT, proxies y rotación de keys rompen la equidad y la auditabilidad. Utilice la organización o el proyecto como clave primaria y la IP como guardrail.
- Hacer que los clientes reintenten a ciegas. Los reintentos inmediatos amplifican la congestión. Respete
Retry-After, use backoff exponencial y limite los intentos. - Monitorear solo los ingresos o la tasa de 429. Un aumento en los ingresos puede coincidir con un menor éxito, mientras que una tasa baja de 429 puede significar una sobre-reserva. Monitoree la experiencia, el costo y la confiabilidad en conjunto.
- Reemplazar la política con una excepción de ventas. Una puerta trasera indocumentada es difícil de revocar e injusta. Utilice un proceso de capacidad reversible, auditable y con límite de tiempo.
Preguntas de seguimiento y respuestas
Un cliente recibe errores 429 durante una ráfaga a pesar de que le queda mucha cuota mensual. ¿Qué hace usted?
Explique que una cuota de período y una tasa instantánea son promesas distintas. Inspeccione el costo del endpoint y el flujo de trabajo del cliente, y luego agregue una asignación de ráfaga justificada o una vía para solicitar ráfagas temporales. Documente el comportamiento de reinicio y espera en encabezados, documentación y el panel de control. No aumente las RPM de todos los clientes sin evidencia.
Un cliente grande solicita omitir los rate limits. ¿Acepta?
Solicite información sobre su carga de trabajo, costos de dependencia y objetivos de confiabilidad. Ofrezca capacidad reservada, una cola dedicada o un incremento con límite de tiempo manteniendo los guardrails de seguridad de todo el sistema. Registre la aprobación, el precio, la expiración y el plan de rollback. Una promesa ilimitada transfiere el riesgo a otros clientes y a los servicios downstream.
La tasa de 429 disminuye pero la retención también cae. ¿Cómo decide si la política falló?
Segmente por endpoint, nivel, carga de trabajo y fase de migración. Verifique si un límite más amplio ocultó costos o latencia, y luego combine llamadas exitosas al primer intento, contactos de soporte, alertas de presupuesto y entrevistas de churn. Si solo sufren los flujos de trabajo críticos, corrija las unidades, la documentación o la política de ráfagas antes de eliminar todos los guardrails.
Los clientes comparten un presupuesto entre varios proyectos. ¿Cómo evita que un proyecto agote la asignación de la organización?
Utilice dos niveles: un presupuesto a nivel de organización más concurrencia o reservas a nivel de proyecto. Los endpoints costosos o riesgosos pueden requerir una reserva por proyecto. Muestre ambos valores restantes en el panel de control e identifique si un error es a nivel de proyecto o de organización para que un administrador pueda ajustar el presupuesto o la prioridad.