Limitación de velocidad en Microsoft Fabric

Microsoft Fabric usa la limitación de velocidad para mantener el rendimiento y la fiabilidad del servicio cuando las cargas de trabajo superan los límites de capacidad o de solicitudes de la API REST. En este artículo se explica cómo funciona la limitación, cómo interpretar las respuestas HTTP 429 y cómo diseñar aplicaciones que controlan las cuotas de API de Fabric de forma eficaz.

Límites de cuota de API

Microsoft Fabric está introduciendo la cuota unificada para las API REST para sus API REST. En este modelo, las solicitudes de API se rigen por cuotas de nivel de identidad aplicadas por usuario o entidad de servicio.

El objetivo es ofrecer una experiencia de limitación de tasa coherente y predecible para los grupos de API sujetos a gobernanza, en escenarios de automatización, de CI/CD y impulsados por agentes.

Anteriormente, cada Microsoft Fabric API REST aplicaba sus propias reglas de limitación independientes, lo que a menudo provocaba un comportamiento incoherente entre los puntos de conexión. Como resultado, era difícil predecir cuándo se podría limitar una carga de trabajo, especialmente para escenarios de automatización que interactúan con varias API y estaban sujetos a distintos límites.

Con la introducción de APIs Quota, Fabric adopta un enfoque más coherente basado en la identidad. El consumo de API ahora se rige por una cuota unificada que se aplica por identidad, lo que proporciona un modelo de limitación más claro y predecible en Fabric API. Sin embargo, es importante tener en cuenta que algunos límites de limitación específicos de cada API pueden seguir aplicándose además de la cuota general de las API.

Cuando una página de referencia de API documenta una cuota, trate ese límite específico del punto de conexión como autoritativo para esa API. Si una página de referencia de una API no indica una cuota numérica, diseñe su aplicación para gestionar las respuestas 429 respetando Retry-After, aplicando reintentos limitados y evitando los picos de tráfico.

Funcionamiento del modelo de cuota

A cada identidad (ya sea un usuario o una entidad de servicio) se le asignan varios cubos de cuota independientes que rigen diferentes categorías de tráfico de API. Cuando la identidad envía una solicitud, la solicitud se evalúa con respecto a la cuota de la categoría de API que se usa.

Hay tres cuotas unificadas:

1. Cuota unificada para las API de plataforma — dedicada a las API de plataforma.
2. Cuota unificada para las API del programador de tareas, dedicada a las API del programador de tareas.
3. Cuota unificada para las API de operaciones de larga duración — dedicada a las API de operaciones de larga duración.

Dado que estas cuotas son independientes, la actividad de una categoría no consume cuota de otra categoría. Por ejemplo, una entidad de servicio podría consumir su cuota unificada completa para las API del programador de trabajos sin afectar a su cuota unificada disponible para las API de plataforma. Esta separación garantiza que las cargas de trabajo de gran volumen en áreas de API especializadas no afecten a las operaciones generales de API y permiten un comportamiento de limitación más predecible en distintos tipos de solicitudes.

Aplicación de la API

La cuota de API se aplica por identidad, lo que significa que cada usuario, entidad de servicio o identidad administrada recibe su propia asignación de cuota independiente. Las cuotas nunca se comparten entre identidades y todas las API de Fabric aptas consumen desde un cubo de cuota común asociado a esa identidad.

Como resultado, el uso de API por una identidad no afecta a ninguna otra identidad. Por ejemplo, una entidad de servicio muy usada puede agotar su propia cuota de API sin afectar a las cuotas de otros usuarios o aplicaciones.

Del mismo modo, si una identidad alcanza su límite de cuota y se limita, esa limitación solo se aplica a esa identidad, mientras que otras identidades siguen funcionando normalmente. Este aislamiento proporciona un consumo de API más predecible y manejable en todas las cargas de trabajo.

Jerarquía de aplicación de cuotas

Cada solicitud de API comienza con una identidad, ya sea una cuenta de usuario o una entidad de servicio. Cuando esa identidad llama a una API de Fabric, la solicitud consume primero la capacidad de la cuota de API compartidas, que se aplica por identidad en lugar de por API. Esta cuota actúa como un mecanismo de limitación centralizado que se comparte entre todas las API participantes, lo que garantiza que una sola identidad no puede superar la tasa de solicitudes asignada.

Después de evaluar la solicitud con respecto a la cuota de API compartidas, también se aplican los límites de limitación específicos de la API. Estos límites son independientes de la cuota compartida y pueden existir solo para determinadas API. Como resultado, una solicitud debe satisfacer la cuota de API de nivel de identidad y los límites de API individuales aplicables para que se procesen correctamente.

En términos prácticos, la cuota de API compartidas proporciona una experiencia de limitación coherente entre las API, mientras que los límites de API individuales siguen protegiendo servicios específicos que requieren medidas de seguridad adicionales. Por lo tanto, se puede limitar una llamada API porque la identidad ha agotado su cuota compartida o porque ha alcanzado el límite de un punto de conexión de API determinado.

Conceptos clave:

• Cumplimiento basado en identidades: se realiza un seguimiento de la cuota por separado para cada usuario o entidad de servicio.
• Compartido entre API: las solicitudes a distintas API consumen del mismo grupo de cuotas de API.
• Solo limitación de velocidad: la cuota de las API controla las tasas de solicitudes, pero no afecta a la autorización ni a los permisos.
• Cumplimiento dual: tanto la cuota de API compartidas como los límites específicos de la API se evalúan para cada solicitud.
• El límite más restrictivo gana: se limita una solicitud cuando se supera la cuota compartida o se supera un límite específico de la API aplicable.

Cómo se consume la cuota

Cada solicitud a la API consume parte de la cuota asignada al cupo de cuota de APIs de la identidad que realiza la llamada. Todas las solicitudes realizadas por esa identidad se contabilizan en la misma cuota compartida, independientemente de la API que se llame.

Ventana de cuota y renovación

La cuota de API se aplica mediante una ventana fija de 60 segundos. El cupo se repone por completo cuando finaliza la ventana actual. La cuota no se recupera gradualmente durante el período.

Ejemplo de cronología

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

Implicaciones prácticas

• Se permite realizar solicitudes en ráfaga al inicio de un período, pero hacerlo puede hacer que la identidad quede sujeta a limitación de velocidad durante el resto de ese período.
• Distribuir las solicitudes de forma uniforme a lo largo del período de 60 segundos ayuda a evitar la limitación de velocidad.
• Respeta siempre el encabezado de respuesta Retry-After. Indica cuánto tiempo debe esperar antes de volver a intentar una solicitud limitada.

Detalles del límite de velocidad por API

Aunque Microsoft Fabric proporciona categorías de limitación unificadas y conceptos de cuota compartida, los límites de velocidad reales pueden variar según la API. Compruebe siempre la sección Límites de limitación de la API específica a la que llama.

Mensaje de limitación de velocidad

Cuando se aplica la limitación de velocidad, Fabric devuelve un código de estado HTTP 429 (Demasiadas solicitudes). Fabric devuelve un código de estado 429 por dos motivos distintos, cada uno identificado por un diferente errorCode en el cuerpo de la respuesta:

• Límite de frecuencia superado (RequestBlocked)
• Límite de capacidad superado (CapacityLimitExceeded)

Inspeccione el errorCode valor en la respuesta para determinar qué condición se produjo y cómo responder.

Límite de velocidad superado (RequestBlocked)

Cuando un usuario envía muchas solicitudes que superan un límite predeterminado durante un período de tiempo, Fabric limita las solicitudes adicionales de ese usuario durante un breve período.

En este caso, Fabric devuelve un código de estado HTTP 429 (demasiadas solicitudes) con un Retry-After encabezado HTTP en la respuesta, lo que indica cuántos segundos debe esperar la aplicación que realiza la llamada antes de volver a intentar la llamada. El cuerpo de la respuesta usa el código de error RequestBlocked:

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

Cuando reciba este error, espere la duración especificada en el Retry-After encabezado antes de volver a intentar la solicitud.

En la captura de pantalla siguiente se muestra un ejemplo de respuesta, lo que sugiere que el usuario espera 55 segundos antes de volver a intentar la llamada.

Límite de capacidad superado (CapacityLimitExceeded)

Fabric también devuelve un código de estado HTTP 429 (Demasiadas solicitudes) cuando la capacidad de Fabric de la organización ha superado sus límites. A diferencia de la limitación de tasa, esta restricción no se debe al número de llamadas a la API que realiza un cliente concreto. Más bien, esto ocurre cuando la capacidad de proceso (unidades de capacidad) consumida por su capacidad supera los límites de la SKU de Fabric adquirida. El cuerpo de la respuesta usa el código de error CapacityLimitExceeded:

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

Cuando reciba este error, vuelva a intentar la solicitud más adelante. Dado que esta restricción depende de la capacidad de proceso total consumida en su capacidad, y no de su tasa individual de solicitudes, es poco probable que volver a intentarlo de inmediato tenga éxito hasta que el uso de proceso de la capacidad vuelva a situarse dentro de sus límites. Si encuentra este error con frecuencia, considere escalar verticalmente o escalar horizontalmente su capacidad de Fabric. Para obtener más información sobre las unidades de capacidad, las SKU y cómo se consume la capacidad de Fabric, consulte Planifique el tamaño de su capacidad.

Consideraciones y limitaciones

Todas las API de administración de Fabric y las API públicas principales de Fabric pueden someterse a limitación de velocidad.

Tenga en cuenta estas consideraciones al diseñar aplicaciones que llaman a Fabric API REST:

• Las cuotas se aplican a la identidad de quien realiza la llamada y a la API invocada. Las identidades independientes no comparten necesariamente el mismo contador de solicitudes, pero cada llamador debe seguir los límites documentados de la API.
• Muchos límites de velocidad se evalúan en intervalos de un minuto. Si supera un límite, espere el valor Retry-After antes de enviar más solicitudes.
• La limitación de capacidad es diferente de la limitación de velocidad de solicitud. CapacityLimitExceededindica que la capacidad de Fabric está sobrecargada, no que el autor de la llamada superó una cuota de API por minuto.
• Es poco probable que reintentar inmediatamente tras un error de limitación de capacidad tenga éxito. Use una directiva de reintento limitada e investigue el uso de la capacidad si el error persiste.
• Para las integraciones de gran volumen, prefiera las operaciones de lista, masiva o por lotes cuando estén disponibles, almacene en caché los metadatos que cambian con poca frecuencia y propague las solicitudes uniformemente con el tiempo.
• En el caso de las API que admiten la paginación, use tokens de continuación en lugar de realizar consultas amplias repetidas desde el principio.

Preguntas más frecuentes

¿Cómo sé si he alcanzado una cuota de API o un límite de capacidad?

Compruebe el errorCode en el cuerpo de la respuesta 429. RequestBlocked significa que la tasa de solicitudes superó los límites de limitación del servicio. CapacityLimitExceeded significa que los recursos de proceso consumidos en la capacidad de Fabric superaron los límites del SKU adquirido.

¿Cuándo se restablece mi cuota?

Muchos de los límites de frecuencia de la API REST de Fabric se evalúan en intervalos de un minuto. Si la respuesta incluye un Retry-After encabezado, use ese valor como tiempo de espera autoritativo antes de volver a intentarlo.

¿Puedo comprobar mi cuota de API restante antes de realizar una solicitud?

Las respuestas de la API REST de Fabric no proporcionan un contador general de cuota restante para todas las API. Desarrolle clientes para que puedan detectar respuestas con código 429, respeten Retry-After y reduzcan el volumen de solicitudes cuando se produzca una limitación de velocidad.

¿Cómo puedo reducir las probabilidades de que se limite la velocidad?

Use operaciones masivas y por lotes cuando estén disponibles, prefiera las API de lista en muchas llamadas de recursos únicos, almacenar en caché metadatos a los que se accede con frecuencia y evitar ráfagas de tráfico repentinas. Para la limitación persistente de la capacidad, use la aplicación Métricas de capacidad de Microsoft Fabric para identificar las capacidades y las cargas de trabajo sobrecargadas.

¿Debo volver a intentar cada respuesta 429 de la misma manera?

N.º Para RequestBlocked, espere a recibir el encabezado Retry-After y luego vuelva a intentarlo con una política de reintentos limitada. Para CapacityLimitExceeded, vuelva a intentarlo más adelante con retroceso exponencial e investigue el uso de la capacidad si el problema continúa.

Contenido relacionado

• Uso de las API REST de Microsoft Fabric
• Ámbitos
• Solución de problemas de Microsoft Fabric API REST
• Planeamiento del tamaño de la capacidad
• Descripción de la limitación de capacidad de Fabric
• Aplicación de Microsoft Fabric Capacity Metrics