Rate limiting hacia afuera: por qué limitarte a ti mismo es parte de la ingeniería
Casi toda la conversación sobre rate limiting es sobre proteger tu propia API de abuso externo. La mitad menos discutida es limitarte a ti mismo frente a las APIs de terceros que consumes.
Cuando se habla de rate limiting, casi siempre se habla de proteger la propia API contra clientes que hacen demasiadas peticiones. Hay una mitad de este problema que se discute mucho menos y que se vuelve crítica en cuanto un sistema orquesta múltiples cuentas o identidades hacia una plataforma externa: limitarse a uno mismo frente a las reglas de esa plataforma, antes de que sea ella quien lo haga por las malas.
Por qué el problema cambia con múltiples identidades
Respetar el límite de tasa de una API externa con una sola cuenta es relativamente simple: la documentación dice cuántas peticiones por minuto están permitidas, y basta con no superarlas. El problema se vuelve genuinamente distinto cuando el sistema orquesta docenas de cuentas hacia la misma plataforma, porque el límite ya no es solo "cuántas peticiones por minuto en total", sino con frecuencia también "cuántas peticiones por minuto por cuenta individual", y ambos límites hay que respetarlos simultáneamente sin que una cuenta ruidosa consuma el presupuesto de tasa de las demás.
El riesgo que no es solo un error 429
El costo de exceder un límite de tasa casi nunca es solo una respuesta de error que se puede reintentar sin consecuencias. Muchas plataformas tratan el exceso sostenido de límites como una señal de comportamiento sospechoso, y responden no con un simple error, sino con restricciones progresivas: límites más estrictos durante un periodo, revisión manual de la cuenta, o en casos extremos, suspensión temporal o permanente. Un sistema que trata cada 429 como "reintentar después" sin ajustar su comportamiento futuro está, poco a poco, empujando sus propias cuentas hacia esa zona de riesgo.
Diseñar el límite propio antes de que lo imponga el proveedor
La respuesta madura no es reaccionar al límite del proveedor, es modelarlo explícitamente dentro del propio sistema, por cuenta y de forma agregada, y dejar que la lógica de negocio espere su turno de forma predecible en lugar de descubrir el límite por fuerza bruta. Esto requiere tratar "cuánta capacidad de petición le queda a esta cuenta en este minuto" como un dato de primera clase que el sistema consulta antes de actuar, no como una consecuencia que se descubre después del hecho.
Esto también cambia cómo se distribuye el trabajo entre identidades: si una cuenta se acerca a su límite mientras otras tienen margen disponible, la operación pendiente puede reasignarse a una cuenta con capacidad libre, en lugar de forzar un reintento contra la misma cuenta ya saturada.
La lección
El rate limiting hacia afuera rara vez aparece en el diseño inicial de un sistema, porque en los primeros meses, con poco volumen y pocas cuentas, simplemente no se manifiesta como un problema. Aparece exactamente cuando el sistema empieza a tener éxito y escala, que es también el peor momento para descubrirlo de forma reactiva. Diseñarlo con anticipación no es paranoia, es reconocer que cualquier integración con una plataforma externa impone un contrato implícito, y que respetarlo de forma proactiva es más barato que reparar la reputación de una cuenta después de perderla.