Respuesta Rápida:
El límite de tasa es la forma en que un servidor le dice a una app que "pidió demasiado, espera". Según MDN, cuando se supera el límite el servidor responde con HTTP 429 Too Many Requests y opcionalmente un encabezado Retry-After indicando cuántos segundos esperar. Toda API seria, desde Stripe hasta OpenAI, lo aplica para proteger su infraestructura.
Puntos Clave:
- HTTP 429 es el código oficial: según MDN, indica que "el cliente ha enviado demasiadas peticiones en un tiempo dado". Está definido en el RFC 6585.
- Retry-After te dice cuánto esperar: el encabezado de respuesta indica los segundos a esperar antes de reintentar. Por ejemplo, Retry-After: 3600 significa esperar 60 minutos.
- Stripe rechaza millones de peticiones al mes: el ingeniero Paul Tarjan reportó en el blog de Stripe que su rate limiter "ha rechazado millones de peticiones solo este mes".
- El algoritmo dominante es token bucket: Stripe lo confirma: "Usamos el algoritmo de token bucket para limitar la tasa" e implementa el sistema con Redis.
- Existen 4 tipos de limitadores en producción: Stripe usa request rate limiter, concurrent requests limiter, fleet usage load shedder y worker utilization load shedder — capas que rechazan tráfico de menor prioridad antes que crítico.
Si alguna vez una integración de tu tienda dejó de funcionar al mediodía un lunes, si tu chatbot de IA empezó a responder con frases cortadas durante una promoción, o si tu pasarela de pagos rechazó silenciosamente algunas transacciones en Black Friday, lo más probable es que te chocaste contra un límite de tasa. No es un error de tu equipo. Es un mecanismo de defensa que toda API seria del mundo aplica para sobrevivir.
Este artículo explica qué es exactamente el límite de tasa, por qué existe, cómo lo aplican empresas como Stripe — que procesa miles de millones de dólares en pagos al año — y, lo más importante, qué señales debes vigilar en tu propio negocio para detectar que una API te está limitando antes de que un cliente lo note. Ya sea que operes una tienda en Houston, Cypress, Monterrey o Bogotá, este es el tipo de fricción técnica invisible que separa una experiencia digital fluida de una que pierde ventas en silencio.
¿Qué es exactamente el límite de tasa?
El límite de tasa (en inglés, rate limiting) es un mecanismo por el cual un servidor restringe cuántas peticiones acepta de un cliente en un período de tiempo determinado. Cuando un cliente excede ese límite, el servidor rechaza la siguiente petición.
Según la documentación de Mozilla (MDN), cuando esto sucede el servidor responde con el código HTTP 429 Too Many Requests, que indica formalmente que "el cliente ha enviado demasiadas peticiones en un tiempo dado". MDN aclara que el mecanismo "se conoce comúnmente como rate limiting — una forma de pedirle al cliente que disminuya el ritmo de sus peticiones". Es un código estandarizado del IETF, definido en el RFC 6585.
La respuesta 429 suele venir acompañada de un encabezado clave: Retry-After. Este encabezado le dice al cliente cuántos segundos debe esperar antes de volver a intentar. MDN da un ejemplo concreto: una respuesta con Retry-After: 3600 significa que el cliente debe esperar 3600 segundos — sesenta minutos — antes de retomar las peticiones.
Lo que pasa por detrás: el servidor no te tira la conexión a la cara. Te responde con un código HTTP y, si el desarrollador de la API es disciplinado, también con instrucciones precisas para reintentar. El problema es que muchas integraciones mal construidas no leen ese encabezado y reintentan inmediatamente — empeorando la situación y a veces gatillando bloqueos más largos.
Cómo lo aplican las APIs profesionales: el caso Stripe
Pocas empresas han documentado su arquitectura de límite de tasa con tanta transparencia como Stripe, la pasarela de pagos que procesa transacciones para millones de comercios alrededor del mundo. En un artículo del blog de ingeniería de Stripe escrito por Paul Tarjan, la empresa describe exactamente qué tipos de limitadores usa y por qué.
Según Stripe, su plataforma usa cuatro tipos diferentes de limitadores, no uno solo:
1. Request Rate Limiter (limitador por peticiones por segundo). Restringe a cada usuario a N peticiones por segundo. Stripe reporta sobre este limitador: "Nuestros límites de tasa de peticiones se gatillan constantemente. Ha rechazado millones de peticiones solo este mes". Esto da una idea de la escala: el rate limiter es la primera línea de defensa y se activa millones de veces.
2. Concurrent Requests Limiter (limitador de peticiones concurrentes). Limita cuántas peticiones simultáneas en curso puede tener un cliente. Stripe describe: "Nuestro limitador de peticiones concurrentes se activa mucho menos seguido (12,000 peticiones este mes)". Es un freno secundario que ataca un patrón distinto: clientes que abren muchas peticiones largas en paralelo.
3. Fleet Usage Load Shedder. Reserva una porción de la infraestructura para peticiones críticas. Stripe lo explica: "si nuestro número de reserva es 20%, entonces cualquier petición no crítica que pase de su asignación del 80% sería rechazada". Es decir, si la flota está bajo presión, las peticiones de menor prioridad se rechazan primero para asegurar que los pagos críticos pasen.
4. Worker Utilization Load Shedder. La última línea de defensa durante incidentes graves. Stripe categoriza su tráfico en "métodos críticos, POSTs, GETs, tráfico de modo prueba" — y descarta el tráfico de menor prioridad cuando la infraestructura se ve realmente amenazada.
Por qué importa esto:
- Una sola capa de rate limit no es suficiente para una API que procesa pagos reales
- Las capas separadas atacan patrones de abuso distintos: ráfagas, paralelismo, sobrecarga sostenida y crisis
- El cliente final puede experimentar "lentitud silenciosa" en lugar de errores explícitos
El algoritmo más común: token bucket
El algoritmo de límite de tasa más usado en la industria — y el que Stripe declara públicamente — es el token bucket (cubeta de fichas). Stripe lo confirma textualmente: "Usamos el algoritmo de token bucket para limitar la tasa".
La idea es sencilla en concepto. Imagina una cubeta que se llena de fichas a un ritmo constante (por ejemplo, una ficha por segundo) hasta un máximo. Cada petición que llega gasta una ficha. Si la cubeta está vacía, la petición se rechaza con un 429. Si está llena, la petición pasa y se gasta una ficha.
La ventaja del token bucket frente a otros algoritmos es que permite ráfagas. Si tu app no hizo peticiones por treinta segundos, acumulaste treinta fichas. Cuando llega un pico real — un cliente abriendo el checkout, una promoción que dispara compras simultáneas — esas fichas acumuladas te dejan pasar la ráfaga sin bloqueo.
Stripe también describe que su sistema "agregó la capacidad de hacer ráfagas brevemente por encima del límite para picos súbitos de uso durante eventos en tiempo real (por ejemplo, una venta flash)". Es decir, las APIs serias diseñan explícitamente para que los picos de tráfico legítimos no te bloqueen.
Stripe también revela el detalle técnico de implementación: "Implementamos nuestros rate limiters usando Redis". Redis es una base de datos en memoria extremadamente rápida que permite coordinar el conteo de fichas entre múltiples servidores en cuestión de microsegundos — algo crítico cuando recibes millones de peticiones por hora.
Cómo te afecta como dueño de negocio
Hasta aquí esto suena como un problema de ingenieros. No lo es. Estos son los escenarios donde un límite de tasa silencioso te cuesta dinero real:
Checkout que carga a medias en horas pico. Si tu tienda integra una pasarela de pagos, una API de envíos y un servicio de impuestos, todas tienen límites de tasa. En un viernes de quincena o un Buen Fin, alguna de esas tres se va a saturar primero. Si tu desarrollador no manejó el reintento con Retry-After, el cliente ve un error genérico — y abandona el carrito.
Chatbot o asistente de IA que se "trabuca" durante una promoción. Toda API de IA aplica límite de tasa por tier de pago. Cuando una campaña dispara conversaciones simultáneas, las respuestas empiezan a tardar 30, 60, 90 segundos. El cliente cierra la pestaña. No te avisa nadie — solo cae la tasa de conversión.
Integraciones de inventario o ERP que fallan los lunes. Las sincronizaciones programadas a la misma hora — típicamente al inicio de la jornada — saturan APIs externas y obtienen 429s. Si el sistema no reintenta con backoff exponencial, los datos quedan desactualizados todo el día.
Anuncios pagados con pixel mal cargado. Si tu sitio dispara muchos eventos al pixel de Meta o Google Ads en una página lenta, el navegador del usuario puede cortar peticiones antes de enviarlas. Pierdes señal de conversión y el algoritmo de anuncios optimiza con datos incompletos.
El patrón común: el cliente final no ve un error técnico. Ve "el sitio está lento" o "no me cargó el botón de pago". Atribuye la culpa a tu marca, no a una API ajena. Y la próxima vez compra en otro lado.
Cómo detectar si tu app tiene un problema de límite de tasa
Hay señales que un dueño de negocio puede revisar sin ser técnico:
Pídele a tu equipo o agencia que revise los logs del servidor de los últimos 30 días buscando códigos 429. Si aparecen más de unos pocos por día, hay un patrón de saturación que están viviendo tus clientes. Que te enseñen el conteo por día y por hora.
Mide los tiempos de respuesta de tus integraciones críticas — pasarela de pagos, búsqueda interna, chatbot, función de "agregar al carrito". Si alguna pasa de 2 segundos en horas pico, ya estás perdiendo clientes incluso si no ves errores explícitos.
Audita los Core Web Vitals de tu sitio en Google Search Console. Las métricas LCP (Largest Contentful Paint) e INP (Interaction to Next Paint) son señales directas de problemas de saturación bajo carga. Google también las usa como factor de ranking, así que la fricción técnica se convierte en menor visibilidad SEO al mismo tiempo.
Pregúntale a tu equipo si tus integraciones implementan reintento con backoff exponencial cuando reciben un 429. Si la respuesta es "no" o "no sé", tienes una mejora obvia que recuperar dinero perdido sin mover ni un peso de marketing.
"El error 429 no es un error de tu negocio — es un mensaje del servidor diciéndote 'tu app no está manejando bien las ráfagas'. La diferencia entre las apps que escalan y las que se rompen está en cómo responden al límite, no en si nunca lo tocan."
- Diego Medina F, Fundador de MerchandisePROS
Qué Significa Esto Para Tu Negocio
Si tu sitio web es el motor de ventas — tu tienda online, tu sitio de captación de leads, tu portal de citas — entonces los límites de tasa silenciosos son una de las fuentes más caras y menos visibles de pérdida de ingresos. No salen en Google Analytics. No los reporta tu agencia. Solo se manifiestan en métricas que ya están sangrando: menor conversión, menor tiempo en sitio, mayor rebote, peor ranking en Google.
La Consultoría Web (Website Consulting) de MerchandisePROS está diseñada exactamente para esto. Auditamos la experiencia técnica completa de tu sitio: tiempos de respuesta de cada integración, manejo de errores 429 en logs, Core Web Vitals bajo carga real, y patrones de saturación en horas pico. El entregable es concreto: un reporte con cada problema detectado, su impacto estimado en conversión, y la corrección técnica que tu equipo o tu agencia debe implementar. No te vendemos código — te damos el mapa para que quien ya escribe tu código sepa exactamente qué arreglar.
Empieza con la auditoría gratis de 60 segundos. Detecta de inmediato si tu sitio tiene fricción técnica oculta que está costándote ventas.
Preguntas Frecuentes
¿Qué es el límite de tasa (rate limiting)?
El límite de tasa es un mecanismo donde un servidor restringe cuántas peticiones puede hacer un cliente en un período dado. Cuando se supera el límite, el servidor responde con el código HTTP 429 Too Many Requests, indicando — según MDN — que "el cliente ha enviado demasiadas peticiones en un tiempo dado".
¿Qué significa el error HTTP 429?
HTTP 429 Too Many Requests es un código de error del cliente que indica que se enviaron demasiadas peticiones en un período dado. La respuesta suele incluir un encabezado Retry-After que le dice al cliente cuántos segundos esperar antes de reintentar. Está definido en el RFC 6585 del IETF.
¿Por qué mi app silenciosamente se vuelve lenta cuando hay tráfico alto?
Muchas APIs aplican un "load shedder" que rechaza peticiones de baja prioridad sin avisar al usuario final. Stripe, por ejemplo, reserva una fracción de su infraestructura para peticiones críticas y rechaza peticiones no críticas que superen su asignación. El resultado para el cliente final: páginas que cargan a medias, respuestas parciales o tiempos de espera largos sin un error visible.
¿Qué algoritmo usan las APIs serias para limitar peticiones?
El más común es el token bucket. Stripe lo declaró públicamente en su blog de ingeniería: "Usamos el algoritmo de token bucket para limitar la tasa". Permite ráfagas cortas de tráfico (consumir tokens acumulados) y luego se recarga a un ritmo constante. Stripe lo implementa con Redis para coordinar entre servidores.
¿Cómo sé si mi negocio está siendo limitado por una API?
Las señales más comunes son: errores 429 en logs del servidor, retrasos súbitos en checkout o búsqueda en horas pico, funciones de IA que "piensan" más de 30 segundos, e integraciones que fallan en lunes por la mañana cuando todos abren su tienda. Una auditoría técnica detecta estas fallas antes de que un cliente las note.