Límites de frecuencia
La API de Stripe usa una serie de medidas de protección contra los aluviones de tráfico entrante para maximizar su estabilidad. Es posible que los usuarios que envíen muchas solicitudes en sucesión rápida reciban un código de respuesta de error 429
. Estos son algunos de los limitadores que tenemos en la API:
Un limitador de velocidad que limita la cantidad de solicitudes por segundo recibidas por la API.
Para la mayoría de las API, Stripe permite hasta 100 operaciones de lectura por segundo y 100 operaciones de escritura por segundo en modo activo, y 25 operaciones por segundo para cada una de las anteriores en modo de prueba.
Para la API Files, Stripe permite hasta 20 operaciones de lectura por segundo y hasta 20 operaciones de escritura por segundo, tanto en modo activo como de prueba. Cada modo tiene su límite individual.
Para la API Search, Stripe permite hasta 20 operaciones de lectura por segundo, lo cual se aplica a todos los puntos de conexión de búsqueda, tanto en modo activo como de prueba. Cada modo tiene su límite individual.
Un limitador de concurrencia que limita la cantidad de solicitudes activas en un determinado momento. Los problemas con este limitador son menos comunes en comparación con el limitador de velocidad, pero tiene mayor propensión a generar solicitudes de larga duración y con uso intensivo de recursos.
Toma estos límites como valores máximos y no generes una carga innecesaria. Consulta Cómo manejar los límites correctamente donde encontrarás consejos para manejar los errores 429. Si de repente ves que aumenta la cantidad de solicitudes limitadas, contacta con soporte.
Podemos reducir los límites para evitar abusos o aumentarlos para habilitar aplicaciones de alto tráfico. Para solicitar un aumento del límite de frecuencia, ponte en contacto con soporte. Si necesitas un aumento importante, contáctanos 6 semanas antes del momento en que lo necesites.
Causas comunes y mitigaciones
La limitación de velocidad puede producirse en diferentes condiciones, pero es más común en los siguientes casos:
- Ejecutar un gran volumen de solicitudes muy próximas puede llevar a una limitación de la velocidad. A menudo, esto forma parte de operaciones analíticas o de migración. Cuando estés haciendo estas actividades, debes tratar de controlar la tasa de solicitudes de lado del cliente (consulta Cómo manejar los límites correctamente).
- La emisión de muchas solicitudes de larga duración puede activar la limitación. Las solicitudes utilizan diferentes cantidades de recursos del servidor de Stripe. Las solicitudes que demandan más recursos tienden a insumir más tiempo, y esto puede llevar al limitador de concurrencia a suprimir las nuevas solicitudes. Los requisitos de recursos varían mucho, pero las solicitudes de listas y las solicitudes que incluyen expansiones suelen usar más recursos e insumen más tiempo de ejecución. Sugerimos trazar el perfil de duración de las solicitudes de la API de Stripe y observar los tiempos de espera para tratar de detectar aquellas que sean inesperadamente lentas.
- Un aumento repentino en el volumen de cargos, por ejemplo, por una venta con grandes descuentos puede generar un límite de frecuencia. Siempre tratamos de definir límites lo suficientemente altos como para que la gran mayoría de los usuarios no sufran un límite de frecuencia durante el flujo de un pago legítimo, pero si sospechas que un próximo evento podría llevarte a exceder los límites anteriormente mencionados, ponte en contacto con soporte.
Cómo manejar los límites correctamente
Una técnica básica para que las integraciones manejen correctamente los límites consiste en observar los códigos de error 429
y crear un mecanismo de reintentos. Este mecanismo debe seguir un calendario de retroceso exponencial para reducir el volumen de solicitudes cuando sea necesario. También recomendamos agregar algo de aleatoriedad al calendario para evitar el efecto de estampida.
Debido a que las solicitudes individuales se pueden optimizar solo hasta cierto punto, un enfoque más sofisticado consistiría en controlar el tráfico hacia Stripe a nivel global y moderarlo si detectaras una limitación de velocidad importante. Una técnica común para controlar la velocidad es implementar, por ejemplo, un algoritmo de limitación de velocidad “token bucket” de lado del cliente. Hay implementaciones ya preparadas y probadas para “token bucket” disponibles en casi cualquier lenguaje de programación.
Tiempos de espera de bloqueo de objetos
Las integraciones pueden encontrar errores con código de estado HTTP 429
, código lock_timeout
y este mensaje:
No se puede acceder a este objeto en este momento porque otra solicitud de API o un proceso de Stripe ha tenido acceso a él. Si este error aparece en forma intermitente, vuelve a intentar la solicitud. Si el error aparece con frecuencia y estás haciendo varias solicitudes a la vez para un solo objeto, haz las solicitudes de manera secuencial o a menor velocidad.
La API de Stripe bloquea objetos en algunas operaciones para que las cargas de trabajo concurrentes no generen interferencias y resultados incoherentes. El error indicado arriba se produce por una solicitud que trata de adquirir un bloqueo que ya se utiliza en otro lugar y que se agota antes de poder adquirirlo.
Los tiempos de espera de bloqueo y los límites de frecuencia tienen causas diferentes, pero sus mitigaciones son similares. Al igual que para los errores por límite de frecuencia, recomendamos volver a intentar con un calendario de retroceso exponencial (consulta Cómo manejar los límites correctamente). Sin embargo, a diferencia de lo que sucede con los errores por límite de frecuencia, el mecanismo de reintento automático integrado a las librerías de clientes de Stripe hará el reintento de los errores 429
causados por tiempos de espera de bloqueo:
La contención de bloqueo se debe al acceso concurrente a objetos relacionados. Las integraciones pueden reducirlo considerablemente asegurándose de que las mutaciones en el mismo objeto se pongan en una cola y se ejecuten en forma secuencial. Se pueden seguir haciendo operaciones concurrentes con la API, pero trata de cerciorarte de que las operaciones simultáneas se hagan solo sobre objetos únicos. También es posible ver una contención de bloqueo a causa de un conflicto con un proceso interno de Stripe en segundo plano. Es raro, pero debido a que está más allá del control del usuario, recomendamos que todas las integraciones sean capaces de hacer reintentos de solicitudes.
Prueba de carga
Es habitual que los usuarios se preparen para eventos de venta importantes poniendo a prueba la carga de sus sistemas con la API de Stripe en modo de prueba. Por lo general, no recomendamos esta práctica porque los límites de la API son más bajos en modo de prueba, por lo que es probable que la prueba de carga alcance límites que no se alcanzarían en modo activo. Además, el modo de prueba no es un equivalente perfecto de las llamadas a la API en modo activo y puede resultar un tanto engañoso. Por ejemplo, la creación de un cargo en modo activo envía una solicitud a una pasarela de pagos, pero esa solicitud en el modo de prueba es una simulación y, por lo tanto, arroja perfiles de latencia muy diferentes.
Recomendamos, en cambio, crear integraciones que cuenten con un sistema configurable que permita simular las solicitudes a la API de Stripe y que puedas activar para pruebas de carga. Para obtener resultados realistas, deben simular la latencia aguardando un tiempo de suspensión determinado mediante el muestreo de las duraciones de llamadas reales a la API de Stripe en modo activo, desde la perspectiva de la integración.
Asignaciones de solicitud de lectura de la API
Stripe proporciona acceso a sus solicitudes de lectura de la API (GET) para facilitar búsquedas razonable relacionadas con las integraciones de pagos. A fin de maximizar la calidad del servicio para todos los usuarios, Stripe proporciona las siguientes asignaciones para las solicitudes de lectura basadas en el recuento de transacciones:
- Las solicitudes de lectura de la API no deben exceder una proporción promedio de 500 solicitudes por transacción para una cuenta. Por ejemplo, si una cuenta procesa 100 transacciones en un período de 30 días, no deben exceder las 50,000 solicitudes de lectura de la API durante ese mismo período.
- Cuando se usa Connect, una plataforma y sus cuentas conectadas tienen distintas autorizaciones de lectura de la API:
- Cada cuenta conectada tiene su propia asignación para las solicitudes que inician (500 solicitudes por transacción).
- Las plataformas Connect utilizan una asignación independiente para realizar solicitudes de lectura en nombre de sus cuentas conectadas con su clave de API secreta o tokens de acceso OAuth. Esta asignación también es de 500 solicitudes por transacción en función del recuento acumulado de transacciones en sus cuentas conectadas.
- Las proporciones se miden cada 30 días.
- Cada cuenta, independientemente del recuento de transacciones, tiene una asignación mínima de 10,000 solicitudes de lectura por mes.
- Las solicitudes de escritura de la API no tienen límite de asignación.
Las llamadas a los siguientes puntos de conexión de la API no se incluyen en los límites de asignación anteriores:
Para reducir el volumen de solicitudes de API, considera usar Stripe Data Pipeline a fin de obtener una exportación completa de los datos de la API y guardarla en tu base de datos o proveedor local.
Filtra solicitudes para limitar las llamadas paginadas
Algunos puntos de conexión de listas devuelven varias páginas de resultados y es posible que requieran varias solicitudes para devolver el conjunto completo de objetos de la API a fin de operar una lista. Cuando sea posible, aplica los filtros para limitar los resultados de tu lista.